# Adopt Vercel Eve Architecture in a Codex Workspace

A dependency-free build manual for preparing a repository around Eve's filesystem architecture, security boundaries, and evaluation strategy before installing a runtime.

Published: 2026-07-22
Canonical: https://darrylwong.me/posts/adopt-vercel-eve-architecture-in-codex
Topics: Agent Architecture, Codex, Eve, Technical Build Notes

## Keep development and runtime control planes separate

Codex and Eve solve different problems. Codex is the development agent that reads repository guidance, edits files, and validates changes. Eve is a future product-agent runtime for durable sessions, tools, skills, schedules, channels, hooks, sandboxes, and subagents.

That distinction should remain visible in the repository. AGENTS.md guides development work, while agent/instructions.md defines future runtime behavior. A Codex skill does not automatically become a product-agent capability, and runtime instructions should not inherit development-only context without review.

## Adopt the architecture before the dependency

A team can prepare the filesystem, planning documents, capability contracts, runtime instructions, and evaluation placeholders without installing Eve or pretending that a working runtime exists. This creates a reviewable architecture checkpoint before model, provider, persistence, sandbox, credential, and deployment choices are made.

The skeleton reserves clear locations for tools, skills, connections, hooks, schedules, subagents, shared runtime code, sandbox workspaces, and evals. Non-code placeholders keep those directories in version control without creating fake executable modules or accidentally authoring auto-discovered capabilities.

- Keep repository planning and scoped Codex guidance alongside the application.
- Use concise runtime instructions that state which capabilities are actually available.
- Document future tool contracts centrally before implementation.
- Do not add Eve, credentials, external integrations, or deployment during the architecture-only pass.

## Design authority boundaries before tools

Future tools should be read-only by default and operate through narrow typed contracts. Tenant, user, role, and session scope must come from authenticated infrastructure rather than model-controlled arguments. The model may request an action, but it never grants permission to perform it.

Consequential actions need server-side authorization, an exact preview, human approval bound to the material payload, approval invalidation when that payload changes, idempotency, and a durable redacted audit record. Business policy should remain in testable application services rather than model-facing adapters.

## Validate the structure and defer runtime choices

Architecture adoption is complete when the repository structure, planning frontmatter, local links, safety contracts, and absence of installation artifacts have been checked. Deterministic tests remain the primary layer for business rules and authorization; agent evals complement them by testing instruction following, tool choice, refusal, clarification, recovery, and multi-turn behavior.

A later runtime spike should separately choose one business use case, a pinned Eve version, model and provider, authentication, persistence, sandbox policy, audit storage, deployment, and rollback. Keeping those decisions deferred prevents an architecture exercise from silently becoming an unreviewed production integration.

## Sources

- [Read the living build manual](https://gist.github.com/oruenboi/0b62aa40908d9562e4385deb850c2852)