Ch15. Migration and Governance
Migrate existing agents into Eve and establish enterprise governance for agent portfolios.
Key takeaways
- Migrating to Eve is not a code port; it is decomposing capabilities into Eve file slots and durable runtime surfaces.
- Prompts, tools, procedures, cron jobs, memory, and approvals need owners and gates.
- Governance works when CODEOWNERS, PR checklists, release policy, and data governance are enforced per agent.
The goal of migration is not to preserve the old implementation shape. The goal is to remap existing capabilities into Eve's filesystem, runtime, sandbox, approval, and eval model.
Migration Map
| Existing piece | Eve surface |
|---|---|
| system prompt | instructions.md or instructions.ts |
| long procedure | skills/<name>/SKILL.md |
| function calling | tools/<name>.ts |
| external API plugin | connections/ or authored tool |
| memory object | defineState or external DB |
| cron job | schedules/ |
| webhook endpoint | channels/ |
| child agent | subagents/ or defineRemoteAgent |
| code execution | sandbox/ + built-in tools |
| test prompts | evals/*.eval.ts |
Migration Steps
1. Capability inventory
| Class | Example |
|---|---|
| read | CRM lookup, doc search, warehouse query |
| write | ticket creation, refund, email |
| compute | code execution, report generation |
| memory | user preference, progress |
| delivery | Slack, web, email |
| background | scheduled checks, batch work |
Attach owner, data classification, approval requirement, and audit requirement to each capability.
2. Prompt decomposition
| Prompt part | Destination |
|---|---|
| identity and safety | instructions.md |
| task procedures | skills/ |
| team or tenant policy | dynamic instructions/skills |
| tool usage hints | tool description + skill |
| forbidden behavior | instructions + evals |
3. Tool hardening
Do not merely wrap old functions. Add:
- Zod or Standard Schema input validation
toModelOutputredaction- idempotency key
needsApproval- auth scope
- stable error shape
- eval coverage
4. Runtime split
Move model-driven shell/file/script work into sandbox. Keep secret-bearing API calls in app-runtime tools or connections.
5. Eval baseline
Migration does not require identical wording, but it requires stable contracts.
| Baseline | Example |
|---|---|
| success path | top 10 tasks |
| forbidden path | top 10 risky actions |
| authorization | tenant/user cases |
| regression | past production incidents |
Governance Roles
| Role | Responsibility |
|---|---|
| Agent owner | purpose, scope, business KPI |
| Platform owner | deployment, sandbox, auth, observability |
| Security reviewer | tools, connections, data flow, approval |
| Eval owner | regression suite, dataset, release gate |
CODEOWNERS Example
agent/tools/ @security-team @platform-team
agent/connections/ @security-team @data-platform
agent/channels/ @platform-team @security-team
agent/sandbox/ @platform-team @security-team
agent/subagents/ @agent-platform
agent/skills/ @domain-owners
evals/ @eval-owner @agent-ownerPR Checklist
| Change | Required review |
|---|---|
instructions.md | behavior and safety eval |
skills/** | source, version, prompt injection risk |
tools/** | schema, auth, approval, idempotency |
connections/** | token scope, allow-list, approval |
channels/** | route auth, signatures, session ACL |
sandbox/** | network, secrets, retention |
subagents/** | authority reduction/expansion |
evals/** | coverage and flake risk |
Release Policy
| Release type | Gate |
|---|---|
| prompt-only | core eval + negative eval |
| tool added | security review + tool eval |
| connection added | data flow review + auth eval |
| model changed | full eval + cost snapshot |
| channel auth changed | auth/ACL integration test |
| sandbox changed | sandbox smoke + network test |
| Eve version upgrade | manifest/durable session review |
Data Governance
Eve agents can move data through:
- inbound channels
- model provider or AI Gateway
- app-runtime tools
- MCP/OpenAPI connections
- sandbox network egress
- telemetry exporter
- eval reporter
- durable workflow/session state
Track:
| Field | Record |
|---|---|
| data category | public/internal/confidential/regulated |
| processor | provider/service |
| retention | duration and deletion method |
| access | who can see it |
| redaction | where minimization occurs |
| audit | event/log evidence |
Responsible Use
Official Responsible Use makes the deployer responsible for legal and operational safeguards.
| Control area | Question |
|---|---|
| approval policies | Are sensitive, irreversible, regulated, financial, healthcare, employment, housing, legal, safety-impacting, or user-impacting actions gated? |
| tool restrictions | Are default, custom, MCP, and OpenAPI tools least-privilege? |
| route/session auth | Are route auth and session ownership separate? |
| sandbox controls | Is shell/file/web/network access constrained? |
| telemetry exports | Are inputs, outputs, reasoning, and tool results reviewed before export? |
Do not rely on model behavior alone. Eve can be permissive if you omit approval or leave sandbox network egress open.
Maturity Model
| Level | State | Next step |
|---|---|---|
| L1 Prototype | instructions and tools | auth and eval baseline |
| L2 Controlled | approval, auth, evals | observability and runbooks |
| L3 Reliable | CI gate, audit hook, sandbox policy | cost/latency SLOs |
| L4 Governed | ownership, data flow, release policy | trace-to-eval loop |
| L5 Platform | reusable patterns and controls | portfolio governance |
Adoption Order
- Start with low-risk internal read-only agents.
- Build route auth and eval baseline first.
- Add write tools only after approval and audit are ready.
- Move sandbox network to deny/allow-list before production.
- Promote production failures into evals.
- Create shared skill/tool/connection policy as the portfolio grows.