feat: represent Computer and Data as generated Agent Files

[EthanThatOneKid]

Closes #73.

Computer and Data now each have a generated Agent File (system prompt verbatim, allowlisted memory blocks, and the bound tool surface), produced from source by scripts/export-agent-file.ts. eve stays authoritative for behavior; the .af is a projection that other frameworks can import. Nothing generated is ever read back into agent/.

Files

File	Mode	Blocks	Tools	Prompt
agents/@wazootech/computer/computer.af	compiled manifest	6 (2 with values)	55 (12 write, 43 read)	10,417 chars
agents/@wazootech/data/data.af	source (agents/data/agent/)	5 (2 with values)	19 (all read)	2,435 chars

data.af is published to wazootech/data under the same gallery path. This repository's CI is what keeps the two copies from drifting: regenerate here, copy across.

Identity correction

The first cut framed Computer as an engineering agent whose whole job was the factory. That was wrong, and this branch corrects it wherever identity is written down: Computer is Wazoo's general assistant, the operating computer the whole team shares, and engineering is one domain of that job, run as the supervised pipeline. The wording changes in agent/instructions.ts (Identity), the persona and scope blocks of agent/agent-file-declaration.json, Data's side of the split in agents/data/agent/instructions.md and agents/data/agent/agent-file-declaration.json, plus README.md and .github/ARCHITECTURE.md. Pipeline mechanics, station order, approval gates, and tool surfaces are untouched. Regenerating both files carried the corrected prompt into the projections.

How it maps

• Prompt — exported verbatim from the compiled instructions. A reworded or truncated prompt fails the export rather than shipping a file that describes an agent nobody runs.
• Blocks — allowlisted block by block in agent/agent-file-declaration.json. persona and scope publish; factory_brain, user_preferences, run_history, and intake_state export schema-only, each with a recorded reason. An undeclared block, a private block carrying a value, or a shareable block exported empty stops the export.
• Tools — derived, not declared. agent/tools/github__*.ts bind the @github-tools/sdk factories through defineDynamic, so they never appear in .eve/agent-summary.json; the projection enumerates the authored binding files and resolves each tool's description and read/write class from the installed SDK's type declarations. A bound tool with no resolvable description fails loudly, so the surface cannot silently shrink. Parameter schemas are not projected (TypeScript tool code does not run on another framework); each tool carries schema_fidelity: declared plus source_path and source_repository pointers.
• Model — declared, then cross-checked: the export fails if the declared handle and the compiled modelId disagree.
• Skills — exported whole with content and a source URL.
• Not expressed — channels, subagents, schedules, sandboxes, approval tiers, hooks. Approval policy is tiered and risk-scaled, so it travels as the per-tool write flag rather than a flattened default_requires_approval. Messages and credentials are always empty.

Guards

• lib/agent-file-schema.ts — vendored .af contract, so validation needs no network.
• lib/agent-file-privacy.ts — fail-closed privacy and integrity checks (allowlist trace, empty messages, null secrets, secret-shaped-string scan, prompt byte-equality, created_at null for byte stability).
• lib/github-tool-catalog.test.ts — surface completeness, JSDoc description extraction, an assertion that the projected write flag equals the set agent/lib/github/tool-options.ts gates behind approval, and that Data's declared surface is read-only.
• CI builds the manifest and runs check:agent-file and check:data-agent-file, so a committed file that no longer matches its source fails the build.
• 76 tests pass; typecheck clean.

What this does not do

• No Letta import has been demonstrated. proposal: represent Computer and Data as Letta Agent File (.af) checkpoints #73's acceptance criterion 4 wants the generated file imported into a Letta server with the resulting prompt, block labels, and tool schemas pasted on the PR. That needs a server and a key, so it belongs in a manual or scheduled job — not run here.
• No avatar. The gallery layout pairs an agent with an avatar; that belongs with the upstream PR to letta-ai/agent-file, not with the projection.
• Block values are curated, not accumulated. The exported blocks are persona and scope written for a reader who has only the file. Everything operational stays private, which makes the files honest but weak as imports — the deliberate middle proposal: represent Computer and Data as Letta Agent File (.af) checkpoints #73 asked for.

Merge note

Once this lands, agents/@wazootech/computer/computer.af is pinned to the compiled prompt, so any branch that edits agent/instructions.ts has to re-run pnpm run export:agent-file after rebasing or its verify job fails on the regenerated-from-source step. As of this writing session-github-attachment (#69) and discord-mention-gateway (#67) both touch that file and predate the projection, so they will need that regeneration when they rebase.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
computer	Ready	Preview	Sep 22, 2026 5:18pm UTC

[wazoocomputer]

This PR gives Computer and Data each a generated Agent File, built from source by scripts/export-agent-file.ts, so other frameworks can import the pair while eve stays authoritative for how they actually behave. Computer's file is projected from the compiled manifest (.eve/agent-summary.json) plus the authored agent/tools/github__*.ts bindings, which matter because defineDynamic tools never land in the manifest; Data's is projected in source mode from agents/data/agent/ since it has no build yet. The .af output carries the compiled system prompt verbatim, an allowlisted set of memory blocks (only persona and scope export values; the rest export schema-only with a recorded reason), the full bound tool surface with descriptions and a read/write flag, and whole skills.

The guards are the substance here. lib/agent-file-schema.ts vendors the .af contract so validation needs no network, lib/agent-file-privacy.ts fails closed on undeclared blocks, private blocks carrying values, non-empty messages or credentials, secret-shaped strings, prompt drift, and unstable timestamps, and CI runs check:agent-file and check:data-agent-file after build:eve so a committed file that drifted from source fails the build. Closes #73. Note that #73's acceptance criterion 4 (an actual Letta import with the resulting prompt, block labels, and tool schemas pasted back) is not covered: it needs a server and a key, and the PR says so.

File	Status	Changes	What it is
agents/@wazootech/computer/computer.af	added	+1769	Generated Computer .af: manifest-derived prompt, 6 blocks, 55 tools, 3 skills
agents/@wazootech/data/data.af	added	+690	Generated Data .af: source-mode prompt, 5 blocks, 19 read-only tools
agents/data/agent/instructions.md	added	+42	Data's prompt, the source Data's projection reads
agent/agent-file-declaration.json	added	+225	Computer's declaration: model, block allowlist with privacy reasons, GitHub tool surface
agents/data/agent/agent-file-declaration.json	added	+81	Data's declaration: model plus the read-only tool name list
scripts/export-agent-file.ts	added	+287	The exporter: manifest and source modes, validation, privacy checks, --check drift mode
lib/agent-file-project.ts	added	+348	Pure projection from declared source to .af, with deterministic serialization
lib/agent-file-schema.ts	added	+302	Vendored .af format contract and validator
lib/agent-file-privacy.ts	added	+150	Fail-closed privacy and prompt-integrity checks
lib/github-tool-catalog.ts	added	+138	Derives tool names from bindings, descriptions and write class from the installed SDK
lib/github-tool-catalog.test.ts	added	+190	Pins surface completeness, description extraction, the approval split, and Data's read-only surface
lib/agent-file.test.ts	added	+302	Covers schema validity, byte stability, privacy, and integrity
package.json	modified	+4	export:agent-file, check:agent-file, export:data-agent-file, check:data-agent-file
.github/workflows/verify.yml	modified	+14	Builds the manifest, then runs both drift checks
README.md	modified	+14	How to regenerate the files, plus the Data hand-off note
.github/ARCHITECTURE.md	modified	+15	What the projection includes and what stays eve-only
AGENTS.md	modified	+4	Regenerate after agent changes, never hand-edit

[wazoocomputer]

I posted the reviewer summary on #75: #75 (comment)

The comment opens with a short paragraph on what the PR does and why (both agents get a generated .af projected from source, Computer from the compiled manifest plus the defineDynamic GitHub bindings, Data in source mode; eve stays authoritative for behavior, and the guards are the fail-closed privacy checks plus the CI drift checks). Below it is a table breaking down all 17 changed files with status, line counts, and a plain description of each, including the generated .af outputs, the two declaration files, the exporter and its support modules, the tests, and the doc and CI updates. It stays a summary: no approval, no change requests, nothing asked of the author.

Two notes on the run itself. The workspace sandbox refused to start (its snapshot storage is over the plan limit and resets October 1), so the skill files and shell were unavailable; I worked entirely from the GitHub API and read the PR body, the file list, and the new sources directly, which was enough for a factual summary. Nothing in the comment goes beyond what the diff and description show, and the one gap I called out, no demonstrated Letta import for #73's criterion 4, is the PR's own stated limitation. Also worth saying plainly: I summarized rather than verified. This is someone else's pull request, so I did not review it, and the test and typecheck claims in the body are the author's, not something I re-ran. The verify check was still in progress when I looked.

[wazoocomputer]

This adds a generated Agent File for each agent: computer.af projected from the compiled manifest and data.af from Data's authored source, both written by scripts/export-agent-file.ts with eve remaining authoritative and nothing flowing back into agent/. It leans on the split landing in #72, which is why Data's declaration and instructions arrive here alongside the export tooling.

The interesting part is what it refuses to guess. Memory is allowlisted block by block, so persona and scope publish while factory_brain, user_preferences, run_history, and intake_state ship schema-only with a recorded reason; the projection enumerates the authored github__*.ts binding files because defineDynamic tools never surface in the compiled manifest; and parameter schemas are deliberately not projected, with each tool carrying schema_fidelity: declared plus source pointers instead. The vendored contract in lib/agent-file-schema.ts and the fail-closed checks in lib/agent-file-privacy.ts are what let CI catch drift and accidental disclosure without network access.

Worth knowing if you are reviewing against #73: acceptance criterion 4 is not met. No Letta import has been demonstrated, because it needs a server and a key.

File	Change	Notes
.github/ARCHITECTURE.md	+15	Block-shareability decisions and their reasons
.github/workflows/verify.yml	+14	Builds the manifest, runs both drift guards
AGENTS.md	+4	Durable rule for the generated files
README.md	+14	Documents the projection
agent/agent-file-declaration.json	+225	Allowlisted block declarations for Computer
agents/@wazootech/computer/computer.af	+1769	Generated artifact, 55 tools
agents/@wazootech/data/data.af	+690	Generated artifact, 19 tools, all read
agents/data/agent/agent-file-declaration.json	+81	Data's block declarations
agents/data/agent/instructions.md	+42	Data's prompt source
lib/agent-file-privacy.ts	+150	Fail-closed privacy and integrity checks
lib/agent-file-project.ts	+348	The pure projection
lib/agent-file-schema.ts	+302	Vendored .af contract
lib/agent-file.test.ts	+302	Coverage for the projection
lib/github-tool-catalog.test.ts	+190	Surface completeness and write-flag parity
lib/github-tool-catalog.ts	+138	Resolves the dynamic tool surface
package.json	+4	Export and check scripts
scripts/export-agent-file.ts	+287	The exporter CLI

[wazoocomputer]

I hit an error while handling your request (Model provider API error: Authentication Fails, Your api key: ****53a6 is invalid).

Please try again, rephrase, or reach out if it keeps failing.

Error id: 67b8ceda-90d6-4f96-9f93-c02ee968f1ec

[wazoocomputer]

This session could not recover from an error (Model provider API error: Authentication Fails, Your api key: ****53a6 is invalid).

Start a new comment to continue.

Error id: 67b8ceda-90d6-4f96-9f93-c02ee968f1ec

[wazoocomputer]

I hit an error while handling your request (Model provider API error: Authentication Fails, Your api key: ****53a6 is invalid).

Please try again, rephrase, or reach out if it keeps failing.

Error id: ca920684-ea0a-4d9b-8ef8-a53cf7b1b4e5

[wazoocomputer]

This session could not recover from an error (Model provider API error: Authentication Fails, Your api key: ****53a6 is invalid).

Start a new comment to continue.

Error id: ca920684-ea0a-4d9b-8ef8-a53cf7b1b4e5

[EthanThatOneKid]

Change request — needs a rebase, and its own new CI gate means it has to land last

Posted as a comment rather than a formal "request changes" review because GitHub refuses that on your own PR.

The projection itself is solid. I verified it against the real thing rather than the description:

• pnpm run typecheck, pnpm test (52 tests), and pnpm run build:eve all pass on this branch with the env values the new CI step supplies.
• The built route table contains the /eve/v1/discord-mentions route and no longer contains /eve/v1/discord, matching the removal.
• The committed computer.af is byte-stable against pnpm run check:agent-file at this revision (10,417 characters, 55 tools, 3 skills).

Two blocking reasons.

1. It conflicts after #67

#67 landed this morning (e8db892). Both PRs append a step to .github/workflows/verify.yml and both append scripts to package.json, so the merge conflicts in:

.github/workflows/verify.yml
package.json

The resolution is additive but not a one-liner: #67 adds a Build eve app step and this branch adds a Build the compiled manifest step, both running pnpm run build:eve. They should collapse into one step carrying the union of the env values (NODE_ENV, BETTER_AUTH_SECRET, VERCEL_APP_CLIENT_ID, VERCEL_APP_CLIENT_SECRET). Two build:eve runs in the same job would work but doubles the slowest step for no benefit. The package.json conflict is a plain union of the four new *:agent-file scripts.

2. This PR introduces a gate that makes it the terminal PR of the batch

check:agent-file regenerates from agent/instructions.ts and the tool registry and fails on any diff. That means the committed computer.af is only valid for the exact revision it was generated from — and every other open PR here edits agent/instructions.ts or adds a tool:

• #61 (landed) adds the assess_review_depth tool, taking the tool count 55 → 56.
• #69 (landed) and #70 and #59 all edit agent/instructions.ts.

I built the merge of {61, 69, 75} locally to check, and its own new CI step fails:

agent file is out of date with the source projection
  (system prompt: 11540 characters, blocks: 6, tools: 56, skills: 3)

against the committed 10,417 / 55. So merging this before #70 and #59 would put main red the moment either of them lands, and would fail on this branch as-is today.

Please rebase this onto current main last, regenerate both .af files (export:agent-file and export:data-agent-file), and re-run build:eve plus both checks. If you would rather not serialize, the alternative is to move the check:agent-file step out of verify.yml and into a separate scheduled or manual workflow, so the gate does not block unrelated PRs — but the gate is the reason the generated files stay honest, so I would keep it and serialize instead.

Worth a deliberate decision either way: after this lands, every PR that touches agent/instructions.ts or adds a tool must regenerate computer.af or fail CI. That is the normal cost of committing a generated artifact, but it is a new obligation for every future contributor and it is not currently written down in AGENTS.md or the README. Adding one line — "if you changed the instructions or the tool registry, run pnpm run export:agent-file and commit the result" — would save the first person who trips over it a confusing red build.