Ch14. Enterprise Patterns
Combine Eve features into support, research, code, back-office, analytics, and incident-response agent patterns.
Key takeaways
- Enterprise Eve patterns should be classified by authority, context, tools, sandbox posture, and eval gates.
- Support, research, code, back-office, analytics, and incident-response agents need different approval and sandbox policies.
- Reusable patterns reduce design time and make governance reviews repeatable.
This chapter translates Eve capabilities into common enterprise agent patterns.
Pattern 1. Customer Support Agent
Goal: answer customer questions, create tickets, escalate risky changes.
| Surface | Design |
|---|---|
| instructions | support tone, escalation rules |
| skills | refund policy, SLA playbook |
| connections | CRM, ticketing, docs |
| tools | read profile, create ticket |
| approval | refund, account change |
| hooks | audit customer-impacting actions |
| evals | no PII leak, correct escalation |
Read tools and write tools should be separate. Writes need approval and an audit trail.
Pattern 2. Internal Research Agent
| Surface | Design |
|---|---|
| instructions | cite sources, distinguish fact from inference |
| skills | research method, report format |
| connections | docs, warehouse, GitHub |
| sandbox | analysis workspace |
| subagents | source gatherer, critic |
| evals | citation discipline, no unsupported claims |
Use sandbox files for large evidence and summaries. Avoid dumping all context into prompts.
Pattern 3. Code Work Agent
| Surface | Design |
|---|---|
| sandbox | repo checkout and command execution |
| tools | limited deployment or PR actions |
| approval | destructive commands and deploys |
| hooks | command/action audit |
| evals | no unapproved deploy, patch quality |
Separate "generate code" from "perform external write."
Pattern 4. Approval-based Back-office Automation
Workflow:
- collect request
- validate input
- compute risk
- ask for approval
- execute with idempotency key
- write audit ledger
| Surface | Use |
|---|---|
| outputSchema | risk and approval requirements |
| tools | preview and execute separated |
| approval | execute tool always gated |
| hooks | ledger |
| evals | park before write |
Pattern 5. Data Analysis Agent
| Surface | Design |
|---|---|
| connections | warehouse MCP/OAuth |
| sandbox | charts, notebooks, file artifacts |
| skills | analysis method |
| approval | expensive or export queries |
| state | metric definitions |
| evals | query safety and result shape |
Keep credentials in connections. Use sandbox for computation and charting, not token storage.
Pattern 6. Incident Response Agent
| Surface | Design |
|---|---|
| channels | Slack, Linear, GitHub, custom incident webhook |
| schedules | heartbeat and stale incident sweep |
| tools | read logs, create issue, propose rollback |
| approval | production-impacting action |
| subagents | investigator, comms drafter, reviewer |
| evals | severity classification and no unauthorized action |
Incident agents invite over-automation. Production-impacting actions still need ownership checks and approval.
Common Architecture
Capability Design Matrix
| Capability | Eve surface | Control |
|---|---|---|
| stable behavior | instructions | prompt review and eval |
| long procedures | skills | source and version |
| external read | connection/tool | least-privilege token |
| external write | tool | approval and idempotency |
| file/code work | sandbox | network and retention |
| delegation | subagent | output schema and authority split |
| background work | schedules | idempotency and alerts |
| audit | hooks | redaction and durable store |
Operating Template
For each agent pattern, document:
| Question | Artifact |
|---|---|
| Who owns the agent? | owner record |
| What data does it access? | data flow map |
| Which actions require approval? | approval policy |
| What can the model see? | context map |
| What can run in sandbox? | sandbox policy |
| Which evals block release? | eval gate |
| How do we roll back? | runbook |