Agent Build Stack

An Assembly Line agent is a directory. Each file or folder has one job, and the compiler turns that directory into a manifest, runtime artifact, route table, schedule table, and deploy plan.

Only instructions.md and agent.ts are required. Add the rest as the agent grows. Start here: instructions.md and agent.ts — run assembly-line init to scaffold both, then edit them.

agent/
  instructions.md
  agent.ts
  context.ts
  gateway.ts
  tools/
  skills/
  channels/
  automations/
  automation-handlers/
  connections/
  sandbox/
  subagents/
  evals/
  hooks/
  resolvers.ts
  instrumentation.ts

File Map

Path	Purpose	Add it when
instructions.md	Always-on trusted instructions.	You define the agent's role, tone, rules, and durable behavior.
agent.ts	Agent identity, model, reasoning, and policy toggles.	You need a model, stable id, default tools, or runtime capability policy.
context.ts	Context bundle policy.	The default history, memory, files, or trust-boundary behavior needs tuning.
gateway.ts	Portable runtime stack choices.	You choose deploy, state, blob, sandbox, scheduler, or runtime adapters.
tools/	Typed actions the model can call.	The agent needs to do work through reviewed app-runtime code.
skills/	On-demand procedures and reference material.	Guidance is useful only sometimes, or the agent should improve by editing skills.
channels/	External entrypoints and reply delivery.	The same agent should receive HTTP, Slack, Discord, Teams, Telegram, Photon, or custom events.
automations/	Time- or event-triggered runs and trusted lifecycle hooks.	Work should run on cron or in response to an external event.
connections/	External service capability and credential contracts.	Tools need GitHub, MCP, OpenAPI, HTTP APIs, OAuth, or workspace/user credentials.
sandbox/	Isolated filesystem and command execution backend.	The agent needs shell/file work outside the trusted app process.
subagents/	Pi-backed child agents.	A task should run with a narrower identity, model, tool set, workspace, connection set, or durable run boundary.
evals/	Engagement-owned golden dataset.	You need regression checks for agent behavior, tool choices, structured output, cost, or qualitative criteria.
hooks/	Observe-only subscribers to the durable run event stream.	You want to react to what the agent does (persist runs, sync systems, alert) without touching execution. See Customizing Agents.
resolvers.ts	Per-run model, instructions, and tool-set declarations.	The right capabilities depend on who is calling or what the run is about. See Customizing Agents.
instrumentation.ts	Telemetry setup and capture policy.	You want OTLP export or explicit content-capture controls.

Design Rules

• Put behavior in the narrowest file that owns it.
• Put provider event parsing in channels/, not tools.
• Put deployment and storage choices in gateway.ts, not agent.ts.
• Put realtime service access in connections/ and typed tools, not subagent engine configuration.
• Put reusable procedures in skills/, not long tool descriptions.
• Put secrets in environment variables or credential stores, never in model-visible files.
• Treat files, history, memory, search results, webpages, and tool output as untrusted context.
• Write generated artifacts and modified input copies under /workspace.
• In bash, use paths relative to the workspace cwd for local-sandbox portability.

What Happens At Build Time

Assembly Line statically reads the agent directory. The compiler validates known top-level files, extracts define* declarations from TypeScript, records source hashes, and emits .assembly-line/. evals/ is excluded from the revision hash, so changing test cases never creates a new deployment revision.

agent/ source
  -> compiler validation
  -> manifest.json
  -> route-table.json
  -> schedules.json
  -> preflight.json
  -> server/boot.js

For the full artifact shape, see Runtime And Deployment. For every config field, see Configuration Reference.