Appearance
EAS
EAS Tire & Auto: the auto-service enterprise Avoca's voice agents answer for, and the engagement this toolkit is built around. Enterprise 117, ~24 shops, all greenfield. CRM is AutoOps.
This tree holds everything tenant-specific: the shops and their team ids, the credentials, the prompt and how it was built, the call reports, and the worked examples. It's deliberately separate from the Avoca tree, which documents the platform itself.
The three layers
Keeping these apart is what makes either tree readable. The test is a counterfactual: if EAS churned tomorrow and a different AutoOps shop signed, what would still be true?
| Layer | Where | Survives EAS churn? |
|---|---|---|
| Avoca platform — call lifecycle, Blueprint, tool calls, common webhook, testing seams | /clients/avoca/ | Yes, entirely |
| AutoOps integration — the vendor contract: endpoints, auth, error classification, handler patterns | /clients/avoca/crms/autoops/ | Yes — a new tenant reuses all of it |
| EAS tenant — shops, team ids, credentials, the prompt, the reports | here | No |
So AutoOps material lives in the Avoca tree next to HouseCall Pro, because AutoOps is a vendor Avoca integrates with, not a thing EAS owns. EAS is currently the only AutoOps tenant, which makes the two easy to conflate. That's exactly why the line is drawn explicitly.
Where to start
- How I built the EAS prompt — the rework: maxims as spec of record, tabletop dry-run, the rigid/LLM measurement, and the regression corpus that gates changes.
Related
- Avoca platform docs — how the product works, CRM-neutral
- AutoOps integration — the vendor contract
- Daily reports · Weekly reports — EAS call reviews (pending migration into this tree)