Ch4. Compiler and Runtime Graph
How Eve transforms source manifests into compiled manifests and runtime agent graphs.
Key takeaways
- Eve stability comes from separating source manifest, compiled manifest, and runtime graph.
- Tool registries merge framework defaults, authored tools, connections, subagents, and dynamic tools.
.eve/artifacts and manifest versions should be treated as production release evidence.
Eve does not simply interpret source files at runtime. It discovers files, compiles them into artifacts, and resolves those artifacts into runtime registries.
Pipeline Overview
What compileAgent() Means
compileAgent() produces the material the runtime will later load:
- diagnostics
- source discovery manifest
- compiled agent manifest
- module map
- build output metadata
If diagnostics fail, the compiler still writes useful artifacts so operators can inspect what happened.
Manifest Version As An Operations Surface
Manifest shape is an internal contract. When upgrading Eve:
- compare compiled manifest versions
- inspect diagnostics changes
- run evals against old and new builds
- check tool and channel names
- inspect subagent graph differences
Runtime Graph Resolution
Runtime graph resolution hydrates a node for each agent and subagent. It combines authored configuration with framework defaults and runtime helpers.
| Input | Runtime result |
|---|---|
agent.ts | model, output schema, compaction, experimental flags |
instructions.* | always-on prompt |
tools/** | authored tools and default overrides |
connections/** | qualified connection tools |
sandbox/** | sandbox backend and workspace |
subagents/** | callable child agents |
hooks/** | event subscribers |
channels/** | inbound routes and event delivery |
Tool Registry And Name Collisions
| Source | Naming |
|---|---|
| framework defaults | built-in names such as shell/file/search/skill tools |
| authored tools | file stem |
| connection tools | connection__<connection>__<tool> |
| dynamic tools | <fileSlug>__<key> |
| subagents | child agent names |
Override and disable default tools intentionally. If a dangerous built-in tool is not needed, remove it from the agent instead of relying on prompt policy.
Controlling Framework Defaults
| Approach | Use case |
|---|---|
| keep default | safe and needed for the agent |
| override default | add logging, policy, or narrower behavior |
| disable default | remove unnecessary authority |
| split to subagent | give a risky capability to a narrower child agent |
Runtime Nodes Are Independent Units
Each declared subagent is a separate runtime node with its own config, tools, skills, sandbox, and state. This matters for security design. A parent can delegate to a child without sharing every capability.
turnAgent Is A Turn Snapshot
Eve resolves the agent for a turn, including dynamic capabilities and current context. Treat this as the actual execution surface for the turn, not merely the static files on disk.
HMR And Production Prompt Snapshots
Local dev may recompile and hot-reload authored files. Production must pin the build artifacts used for a deployment. A prompt or tool change should be tied to:
- compiled manifest
- eval results
- model id and options
- release notes
- rollback plan
Deployment Gate
| Gate | Standard |
|---|---|
| diagnostics | no unexpected warnings/errors |
| manifest diff | expected changes only |
| default tools | disabled/overridden when risky |
| connection tools | allow/block and approval checked |
| subagents | isolation reviewed |
| evals | strict suite passes |
| artifacts | .eve/ kept as release evidence |