Apollo-1: Reasoning in Structured Logic, Not Weights

A customer writes:

The headphones arrived yesterday, but the left side doesn’t work. Can you refund them? Keep the speaker on the same order.

There are two different problems in that message. Understanding it takes language intelligence: spotting the reported defect, telling two products apart, seeing that only one of them is to be refunded. Actually issuing the refund takes something else entirely — find the right purchase, check the policy, work out the amount, get confirmation, call the refund service, and record what really happened. Apollo-1 handles both in one system. Neural reasoning carries the language; an explicit program carries what the business may do — and that program is a file your company writes, reviews, versions, and owns.

​

How the two halves work together

They are not two services trading messages, and there is no moment where one finishes and hands over to the other. They run as a single computation, and most of what happens in a turn is settled where they meet: a reading the model proposes, weighed against what the program declares; a sentence the model drafts, weighed against what the program has actually established. What is divided is authority, not the work: Three places make the interlock concrete:

• A reading is bounded by what you declared. The model turns “the left one is dead” into facts your program defines. It can only bind values your vocabulary declares, in the shapes it declares — and a value the caller explicitly denied never binds, however the sentence read.
• A draft is graded before it ships. The model phrases the reply, but a mechanical check weighs that draft against what was actually established. It can send back a single correction, or fall back to the words you authored. A fact nobody established is never voiced, no matter how fluent the sentence that would have carried it.
• A decision is not up for negotiation. Whether a rule passes, what a figure computes to, whether a write truly happened — these are computed, and the model gets no vote.

The short version: the model is never trusted on its own, and the program is never asked to understand English. A language model’s reasoning lives in weights you cannot read, and its behavior is sampled; Apollo-1’s decisions are written down in full and run as written.

​

Structure, not meaning

Symbolic AI has been tried before, and it failed for a specific reason: it tried to encode meaning into its symbols. That forced ontologies to describe the world — and the world does not fit. The structures did not carry across domains, and the maintenance cost crushed every implementation. Apollo-1 refuses that job. Its symbols carry structure — roles, relations, conditions, state, what must hold before what — and never meaning. “Refund”, “claim” and “eligible” mean whatever your business means by them; the symbolic side only knows where a value sits, what role it plays, and what depends on it. That refusal is what makes everything else possible. Because the structures describe how a task gets finished rather than what anything means, the same ones recur across industries — and meaning can safely be left to a model precisely because the model is never left with the decision. It is also why an agent is language-agnostic. Structure has no language: “the purchase belongs to this account” is the same condition whether the caller wrote in English, Spanish, or Japanese. The neural half absorbs the difference — reading the message and answering in the caller’s own language — while the logic underneath, and the decision it reaches, are identical. You write the program once, not once per market.

​

Logic, not paths

Here is the distinction that matters most, and the easiest one to miss. You do not draw the conversation. You declare the pieces of logic your business is made of — what can be known, what the agent may do, what must be true before it does it, what it must never do, where the facts come from. Each piece is stated on its own, in structured code you own. At runtime the model reasons across all of them together to work out the path for this particular conversation. The path is computed, not authored. That is what separates Apollo-1 from the two approaches in common use: The practical difference shows up on the conversations nobody drew. A caller who gives the order number immediately does not have to walk the same steps as one who needs help finding it. A caller who changes their mind halfway, or raises a second issue, does not fall off the path — because there was no path to fall off. The business requirements are identical either way, so the program says them once.

​

Where the model comes from

The reasoning had to be learned before it could be run. Apollo-1 was derived from the work of 60,000 human agents across millions of real task-oriented conversations — how a skilled person actually closes a claim, resolves a dispute, knows when to confirm and when to refuse. Much of that does exist on paper somewhere: the policy, the procedure, the escalation path. What does not is the end-to-end — how one real conversation travels from an ambiguous opening to a finished task, through every correction, digression, and half-answer along the way. That part is tacit. It can only be distilled from behavior, which is why it had to come from people doing the work rather than from a specification. What was learned there is the structure of finishing a task through conversation — not the content of any one industry. So the model is domain-agnostic and general-purpose: the same frozen model runs a returns desk, a claims desk, and an HR desk. Your program supplies the domain; the model supplies the reasoning over it. This is also why changing an agent does not mean retraining one. Change the program and the agent changes — no retraining, no model release — and an improvement to the model reaches every program built on it. That is what makes Apollo-1 a foundation model in the strict sense: a language model’s domain is text; Apollo-1’s domain is the programs written for it.

​

What an agent is made of

An agent is its program: a folder of typed YAML your team owns, kept in git like any other code. Each concern has its own file, so the whole thing stays readable end to end. Nothing here is a path. These are the pieces; the runtime works out the route through them.

​

What happens in one turn

These are stages of one computation, not a relay between two systems: both halves are present at each of them.

​

Every turn leaves a record

That sealed record is a trace: the facts used, the rules evaluated and what each did, the values computed, the calls made and what came back. This is a different artifact from a model explaining itself. Written reasoning is generated text, and a model’s account of why it answered is not guaranteed to be the actual cause. A trace is the execution — so “why did you refuse that?” has a literal answer: this rule, this condition, this state. It is also the fastest way to find a defect, because it tells you which part was wrong: the reading of the message, the data that came back, the rule as authored, or the call that failed. Those need different fixes.

​

Reasoning becomes software

Once behavior is a program, it inherits the software lifecycle — and that is the deeper point. An agent is versioned and diffed, reviewed before it ships, tested against scenarios, rolled back by re-publishing the version that worked. It is also written the way software is now written: by coding agents. The program, the runtime call, and the trace all live in one medium a coding agent can read and write, so it can make a change, run it, read what happened, and revise until the behavior holds. Two gates keep that loop honest — one checks that the program holds together structurally, the other runs the agent against real conversations and grades what it actually did. Neither is a matter of opinion, so what a run proves stays proven.

​

Where it fits, and where it doesn’t

Apollo-1 is built for task-oriented work where an organization is accountable for the outcome: returns, claims, bookings, disputes, entitlements, payments. The agent talks to a user but answers to a business — the entity whose policies must be enforced, whose auditors must be satisfied, and whose rules change when the business changes. It makes deliberate trade-offs to do that well. Open-ended creative work — writing, brainstorming, exploratory dialogue, where variation is the value — is better served by a language model, because Apollo-1’s structures exist to enforce consistency. It is not a code-generation model. And for low-stakes, high-variation settings, formal enforcement is cost without benefit.

​

Two surfaces, one agent

Agents are authored in two places that edit the same bundle and run the same engine. The CLI is the developer surface: files, runs, versions, git. The Playground is the working surface for everyone else — watch the agent talk, open any turn’s trace, and change the program in plain language from what you just saw.

​

How it is deployed

The same platform is available two ways. As a service. Use Apollo-1 directly through AUI’s API and SDK. There is nothing to host: publish a version and it is served. As a custom enterprise deployment. The platform is deployed for your organization rather than consumed from ours — cloud-agnostic, and in the region you require — for the stricter security, data-residency, and regulatory obligations that come with regulated industries. Either way, the agents and the tooling are the same. What changes is where the platform runs.