Skip to main content
An Apollo-1 agent is its program: a folder of typed YAML files that states a business, not a runtime. You never describe stages, prompts, or models. You describe what the agent can know, what it may do, what it must never do, and what it says — and the runtime turns that into behavior, turn by turn. Each concern lives in its own file, so the program stays readable end to end:
A handful of more specialized files cover advanced ground — conversation places, procedures, plans, approval chains, org roles — but every program starts with the table above, and only program.yaml is required.

​
Identity: program.yaml

program.yaml holds what the agent is, not what it can do:
  • voice — the agent’s register: tone, brevity, and phrases it must never_say.
  • welcome — the opening line, before the caller says anything.
  • caller and context — who is on the line and which facts the host supplies at session open (given), refreshes, or loads.
  • clock — what “today” means when rules are read against dates.

​
Where the goal and guardrails live

There is no goal prompt. What the agent does is stated by its capabilities, each with its own intent; what it must never do is stated by its policies and obligations — enforced predicates, not advisory text. That separation is the point: identity is declared once, behavior is declared per capability, and constraints are rules the runtime evaluates rather than suggestions a model may forget.

​
How the parts meet at runtime

A caller’s message is routed to a capability by its use_when. The capability names the facts it needs; the runtime establishes them — from context, from sources, from derivations, or by asking the caller in the fact’s own words. Policies gate the action before it proceeds, obligations check the reply before it ships, and every decision lands in the trace with the rule that produced it.

Vocabulary

Facts and records — the nouns everything else is built on.

Capabilities & Policies

What the agent can do, and the gates that govern it.