AI agent architecture: role, runtime, instructions, skills, memory, tasks, channels and gates

This page is AR Labs' reference to the architecture of an AI agent that holds a standing job: its eight components, what each is, how it connects to the others, the design choices available, and the choice we made in each of four agents we run. An AI agent is a language model run in a loop with tools, so it can act, not only reply. The guide to building an AI agent takes the same components in build order; this page is for looking one up. The engineering concerns that cut across the components, such as security, reliability and evaluation, are set out in agentic engineering.

It sits beside the anatomy of a coding agent harness, which covers the parts of a coding agent's harness: instruction files, rules, skills, commands, hooks, subagents and tools inside a program such as Claude Code. That page describes the machinery within one runtime. This one describes any agent with a job that outlasts a conversation, whichever runtime it uses, and adds what such an agent needs beyond a harness: a role, authority, durable records, a task loop and channels.

How the components connect

flowchart TD
  R["Role and authority"] --> I["Instructions"]
  I --> M["Model, inside the runtime"]
  SK["Skills and tools"] --> M
  ST["Memory and state"] <--> M
  T["Task store and loop"] <--> M
  C["Channels"] <--> M
  M --> G{"Gates and checks"}
  G -->|"allowed"| W["Action on the world"]
  G -->|"needs a yes"| P["A person"]
  P --> R

The role and authority are set by a person and expressed in the instructions. The runtime loads the instructions and offers skills and tools to the model. The model reads and rewrites state and tasks, and talks through channels. Every action passes the gates, and some stop there for a person, who also owns the role.

The components

Role and authority. The role is the job, its standing responsibilities and the outcome it is judged on. Authority is a table of what the agent may do alone, what needs a person's yes, and what it may never do. How it connects: the instructions state both; the gates enforce the authority table. Choices: authority by action, by data source, or on a delegation scale. Ours: the marketing manager agent has a three-column table and a fixed division of work (the person writes, the agent researches, recommends, briefs and measures); the strategy agent uses a five-level delegation scale.

Runtime. The agent program that runs the loop: it calls the model, routes tool calls, loads instructions and holds the channels. How it connects: everything else plugs into it, and its loading rules decide when an instruction change takes effect. Choices: session-bound, resident, scheduled or per request; a general agent runtime, a coding agent, or a framework such as Pipecat. Ours: Hermes, Nous Research's open-source runtime, for the resident agent; Claude Code for the strategy agent and coding steps, with Codex for review; Pipecat for the voice agent, Salesbot.

Instructions. What the agent reads about itself. Three kinds belong apart: the standing role, which loads every session; the current work, which changes daily; and reference material read on demand. How it connects: loaded by the runtime into the model's context; they route to memory and skills rather than restating them. Choices: one large file, or layered files with a fixed loading order. Ours: layered, aiming at one place for each rule; the marketing agent's accepted but unbuilt design applies Bateson's logical levels so each level governs the one below it.

Skills and tools. A skill is packaged instructions, with any scripts, that an agent loads only when a task needs it; what it packages is a reusable method for one kind of work. A tool is an action the runtime exposes to the model through a schema, which is the tool's contract. A skill is not yet a capability: a capability is one or more skills combined with the tools, permissions, data, interface, tests and controls that together produce a business outcome, so it draws on every component on this page. How it connects: the runtime lists them; gates sit between a tool call and the world. Choices: build, adapt or install whole; broad or least-privilege tool access. Ours: a public marketing library installed whole, and tool lists cut to the role, such as research agents that hold no tool for starting other agents.

Memory and state. Records that outlive a session: a working-state record that states current truth, decisions with their exact wording and maker, and evidence labelled by how it was obtained. How it connects: read at the start of work and rewritten after it; tasks and decisions cite each other by name. Choices: plain files under version control, a database, an extraction-based memory service, or a knowledge graph. Ours: plain files under git; an extraction plugin was switched off (see agent memory for changing facts).

Task store and loop. Durable tasks with a status each, a rule for choosing the next one, and a write-back after each. How it connects: the loop reads the store, acts through tools, checks the result against evidence and writes back. Choices: an issue tracker, a task file, a task graph, a runtime's built-in board. Ours: an issue tracker for the marketing agent, a cadence state file for the strategy agent, a code-defined stage machine for the voice agent, and a task graph in Beads, Steve Yegge's open-source issue tracker for coding agents, for the coding pipeline.

Channels. How a person and other agents reach the agent, and who may write which shared record. How it connects: requests arrive as messages or files and become tasks; replies leave the same way. Choices: chat, a file mailbox, a web page, pull requests and task notes. Ours: a file-based inbox for requests between agents, chat for conversation and nudges, and one writer per shared document (see interface contracts).

Gates and checks. A gate is a point work cannot pass until a condition is met: an approval, a check, or answers collected. A hook is a script run automatically around an agent's action that can block it. How it connects: between the model's decision and the world, and between a task and "done". Choices: an instruction, a runtime setting or a script; a person's approval; independent review. Ours: hooks and scripted evidence checks around the coding agents, code-owned stage completion in the voice agent, a person at each strategy checkpoint, and runtime protections plus written approval rules for the marketing agent.

Four agents compared

The four agents are the marketing manager agent, a resident agent on a server; the strategy agent, which runs the lab's planning reviews from the year down to the day; Salesbot, a public browser voice agent; and the coding agents of our coding pipeline, each started for one step of one task.

Component	Marketing manager agent	Strategy agent	Voice agent (Salesbot)	Coding agents
Role	Researches, recommends, briefs and measures; a person writes	Runs planning reviews, records decisions, passes direction down	Runs a short sales discovery conversation	One step of a code change: spec, build or review
Judged on	Movement from exposure to responses and conversations	Objectives set and tracked; decisions recorded and passed down	Stages completed, answers read back, call closed	Each acceptance criterion proved; reviewed commit lands
Authority	Prepares alone; publishing, sending, spending need a yes	Routine priorities alone; strategy recommended, a person decides	Talks and records; code decides stage and end	Builds in its own worktree; a person merges
Runtime	Hermes, resident on a server	A skill in a Claude Code session, on request	Pipecat voice server, one pipeline per call	A fresh Claude Code or Codex session per step
Instructions	Identity file and workspace guide, read when a session starts	Role, then a procedure per review, in a fixed order	One table of stages generates prompts and tool schemas	Short instruction maps; step procedures read, never summarised
Skills and tools	53-skill marketing library, web search over MCP, issue tracker	Strategy and escalation skills; task counts, not tasks	One recording tool per question stage	Skills, subagents with pinned models and tool lists
Memory and state	Working-state file, evidence folders, git workspace	State file, strategic and operational state, its own memory log	A database record per call, transcript, per-turn trace	Task metadata written by one script
Task loop	Issues with "blocked by" relations	The review that is due runs next	The stage machine	A stateless driver over the task graph
Channels	Direct chat, a shared channel thread, the mailbox	Interactive with a person; briefs through the mailbox	A WebRTC call in the browser	Pull requests and task notes
Gates	Runtime protections; approval rules in its instructions	A person's decision after each phase	Message guard, input limits, code-owned completion	Hooks, evidence checks, cross-vendor review, a person's merge

What the comparison shows

The agents differ most in where they keep control. The voice agent keeps it in code, because a conversation that must reach an end cannot leave its progress to the model. The coding agents keep it in scripts and hooks, because they run unattended. The strategy agent keeps it with a person at every checkpoint. The marketing manager agent has the widest room to act alone, and its approval rule for outward actions is written in its instructions rather than enforced by its runtime, whose approval mechanism covers risky system commands; a check before those actions is an open design item.

They agree on records. None relies on a conversation or a context window as its memory: every one resumes from files or a database that a fresh session can read.

What exists today

All four agents run. The marketing manager agent runs supervised; scheduled work with execution budgets is designed and not switched on. The strategy agent runs as a skill a person starts; an always-on version was stopped. Salesbot is live and public. The coding pipeline runs our own development, attended and unattended. How we would take a client's agent through these components is set out in how AR Labs builds an agent.