Product promise & message hierarchy

This page is for anyone writing public copy about AI Agent Assembly — the product website, this hub, a README, a conference abstract, a sales deck. It exists because the product’s honest value is narrower than its architecture diagram suggests, and narrower still than the words the category usually reaches for. A reader who discovers an overstated claim after provisioning is a worse outcome than one who reads an accurate limit up front.

It is also for evaluators. Levels 1 to 3 below are the fastest accurate account of what the product does, what is on by default, and what it leaves uncovered.

What governs this page

This brief is downstream of two merged artifacts, and it does not add claims to them:

Ticket references on this page are plain text, not links: the tracker is not publicly readable, so a link would only take a reader to a login wall — and a link checker scores that wall as reachable, which makes the reference look verified when it is not.

Two further sources are chartered but not yet available, so nothing here depends on them: the current-state capability matrix (AAASM-5527, in progress) and the machine-readable capability/evidence manifest (AAASM-5531, not started). Statements that would need either of those to be verified are collected under Provisional rather than asserted.

Precedence. Where this hub still carries the superseded three-layer or “IronClaw five-layer” framing — Security model still carries the five-layer model, at the time of writing; AAASM-5727 removed the three-layer framing and the fallback-chain wording from it and from Glossary — ADR 0033 wins, and ADR 0033 records the gap as a tracked, accepted window. Do not resolve a conflict in the superseded model’s favour.

The two are not equally owned. security-model.md is named in ADR 0033’s migration checklist and is covered by AAASM-5586 / AAASM-5609. glossary.md was named by neither — not by the checklist and not by the claim inventory, whose docs rows reach only README.md and comparison.md — so its residuals sat unowned while looking tracked. Now AAASM-5658, which covered two defects: the eBPF entry saying the sensor catches what the layers above miss — corrected by AAASM-5727 — and the SDK entry, which still says the SDK applies allow/deny decisions, contradicting the advisory finding. That ticket also adds the file to ADR 0033 §E, so the next sweep cannot miss it for the same reason this one did.

Note also that this rule is one-directional — a reader who arrives at those pages first never sees it — so the migration tickets, not this note, are the fix.

Maturity labels (🧪 Release candidate, 🗺️ Planned) belong to Source of truth & status and answer a different question — how finished a feature is. ADR 0033 §6’s terms answer what the product did to an action, when, and on what evidence. The two are orthogonal: a 🧪 Release candidate feature can be Unsupported on a platform, and a shipped feature can be Unmeasured on a path. Cross-reference them; never let one redefine the other.

The promise

There is exactly one. Everything else on this page is a rendering of it at a different depth.

Agent Assembly decides whether an AI agent’s action is allowed before that action runs — on the paths you route through it — and records what was decided, so a risky call can be refused, or blocked pending a decision, instead of discovered afterwards.

Headline and subheadline

For a hero or a first screen, the promise renders as:

Headline

Decide what an AI agent may do — before it does it.

Subheadline

Agent Assembly evaluates the actions you route through it against your policy, refuses them, or blocks them pending a decision, and records what it decided. An action you have not routed through it is not inspected — and the record says so.

These two are not severable. The headline is bounded only by the subheadline; published alone it reads as a claim over all agent behaviour. That is the absolute claim class, which accounts for 37 of the 69 audited rows in the AAASM-5528 inventory — by some distance the most common defect in this product’s published copy. The rule for downstream pages is: the boundary clause appears on the same screen as the headline, above the fold, not in a footnote.

Note what the headline deliberately does not say: “your AI agents”. The possessive quantifies over agents you never routed, which is the wording the table below bans, and it is the same correction AAASM-5528 applied to “three boundaries for every agent” → “for a governed agent”. The indefinite article costs nothing and survives the places non-severability cannot reach — a <title>, an og:title, a search snippet, a chat unfurl, a slide. Metadata surfaces must carry the bounded form, because there is no room beside them for a subheadline.

Clause map

Each clause is expressible in ADR 0033 §6’s vocabulary. If a rewrite of the promise cannot be mapped this way, it is not a rendering of the promise — it is a new claim, and it needs its own evidence.

Progressive disclosure — four levels

A reader should be able to stop at any level and hold a correct picture. Each level adds precision; none of them retracts what the level above said.

Level 1 — one sentence

The promise, verbatim. Nothing shorter is approved, because everything shorter drops the boundary clause.

Level 2 — three steps

1. Route it. An agent is on a governed path when you have put it there: launched through aasm run, or started by a developer-tool integration that writes the proxy settings into the tool’s own configuration, or calling a policy checkpoint from an SDK. Routing is a thing you do, per agent and per launch. An agent you did not route is not on the path.

Not every tool has a managed launch to offer. One shipped adapter returns a launch failure rather than a governed command, and another is hard-capped at observation — for those, no proxy environment is injected and there is no data-path mediation to route into. “Supported tool” and “governable tool” are different lists; check the per-adapter boundaries before implying the second.

2. Decide it. Before the action takes effect, something on the path decides whether it may proceed — and which thing depends on the path. The control plane answers policy, budget and approval questions: allow, refuse, or block pending an approval. Budget exhaustion, a suspended agent and an anomaly detection each resolve to a refusal through that same path.

But the control plane is not always the decider, and copy that says it is will be wrong more often than right. The proxy refuses on its own local configuration for CONNECT-time egress and for LLM-provider hosts — those code paths contain no gateway call at all. A gateway Deny stops bytes in exactly one place: an MCP tool-call envelope on a non-LLM intercepted host with a gateway endpoint configured — and since llm_only defaults to on, those hosts are not intercepted unless an operator says so. Attribute the refusal to whichever component actually made it.

Redaction is a separate stage, not a fourth branch of the same answer: it is the proxy’s outbound credential scan, applied after the connection decision, and it defaults to redact-and-forward. Do not present allow/refuse/hold/redact as one four-way per-action verdict — the API’s five-way RuntimeVerdict is a frozen vocabulary whose derivation is unimplemented and which is surfaced as null, and presenting it as a live outcome is a forbidden design.

3. Show it. Decisions are written to a hash-chained audit log that you can verify yourself with aasm audit verify-chain — that command ships in the open-source build. Where nothing inspected an action, the rule is that the record reports it as Unmeasured rather than as clean, because an uninspected action must never be reported as allowed.

State this as a rule, not as finished behaviour. ADR 0033 §4 mandates it, and the transparent-tunnel path implements it — it persists “forwarded, and nothing looked at it”. But §2 records a live defect on the same path: the CONNECT-level decision event still emits an allow for a connection the proxy is about to tunnel uninspected. Until that is fixed, do not write copy that promises the property holds everywhere today.

Emission is best-effort — say so in the same sentence. The gateway advances the chain head before attempting the send, and on a full channel it logs a warning, increments a drop counter and returns the RPC anyway; several sibling emit sites discard the error with no counter at all. So a decision can be made and its record lost, and a dropped entry is indistinguishable from a deleted one. Three bounds belong together wherever this is claimed: which actions are decided (the governed path), whether the record survives (best-effort), and what verification proves (chain integrity, not whether the log is whole). The boundary clause in the promise covers only the first. This is the same rule-plus-open-defect shape as the note above, and the hub’s own security model already states that absence of an entry is not proof of absence.

Why “route it” is step one. The control plane holds no traffic, so a decision only stops something when a component in front of the action blocks on it. That set — components that block on a gateway answer — has exactly two members today: the proxy’s MCP path, and an SDK shim that honours the answer. It is not the set of everything that can refuse: the proxy’s own CONNECT, DLP and LLM-host refusals are local, and they are real. Routing is what puts an action in front of any of them.

Level 3 — for an evaluator

Agent Assembly is a decision point you place in front of an AI agent’s actions, plus the evidence trail that shows what it decided.

What it decides. Which tools an agent may call, which network destinations it may reach, how much it may spend, and which actions are blocked pending an approval. Policy is versioned YAML/JSON you review through normal Git workflows.

Where the decision is applied. In several places, with genuinely different authority. Resist the urge to number them: they are not an ordered chain, one does not cover for another, and an absent one is a reportable state rather than a silent hand-off to the next. That inference — “the SDK did not see it, so the kernel did” — is the specific error the current architecture exists to stop.

• The sidecar proxy is the strongest one. It refuses at CONNECT time, re-checks the host inside the tunnel, blocks or redacts recognised credentials, and adjudicates MCP tool calls — each of those returns before it dials upstream. This is genuine pre-execution refusal, out of the agent’s process.
• The SDK wraps your framework’s tool seam and raises before the wrapped tool body runs. It is deliberately advisory: it is a defence-in-depth posture, not the authoritative gate, and an agent that does not call it is simply not asking.
• Operating-system-level controls are platform-specific and, where they exist today, they mostly observe. On Linux, eBPF probes report TLS plaintext, process execution and file I/O; they do not participate in any allow/deny decision. There is one opt-in syscall guard that terminates a confined process, and it does so asynchronously — the offending syscall runs once before the process dies, so it is Detected, not Denied before execution. macOS has no equivalent adapter, and is simultaneously the only platform where the host-enforcement rung is reachable — through an opt-in, authorized managed-settings write. Both halves are required; writing only the first is the understatement this page bans two sections down. Windows has neither.

What is on by default, and what is not. This is the question that most changes an evaluation:

What it does not do. It does not govern an agent you did not route. It does not inspect payloads to hosts it is not intercepting. It does not keep a credential out of the agent’s own process — what it does is scan outbound requests on the inspected hosts and remove recognised credentials before forwarding. Its audit chain is tamper-evident, not signed: it is an unkeyed digest chain over the JSONL sink, so anyone able to rewrite that file can recompute it, the database mirror carries no chain, and a dropped entry fails verification the same way tampering does. Nor does a passing verification mean the log is whole — it checks the links between the entries that are there, so a deleted-and-recreated log verifies clean. On Windows there is no local mediation at all.

Level 4 — technical handoff

At this depth, stop paraphrasing and hand the reader the canonical sources. ADR 0033 describes the architecture as six roles — a control plane, managed execution checkpoints, protocol/transport mediation, platform-specific host-level adapters, a credential/capability boundary, and an evidence pipeline. A deployment instantiates some subset of them, an absent role is a reportable state rather than a silent fall-through to another role, and each role’s authority is its own.

Send the reader to ADR 0033 §5.3 for the per-platform matrix and §6 for the vocabulary itself. Do not restate either here; both are snapshots of a specific release and are maintained where they live. One thing §5.3 says that a summariser reliably drops: its macOS row ends “Do not read this as ‘no host enforcement on macOS’.” Carry that sentence with the row, not just the row.

Approved plain-language wording

ADR 0033 §6’s terms are precise but they are engineering vocabulary. Public copy needs plain-language equivalents that mean the same thing to a PM, an SRE and a security reviewer. These are the approved renderings. Use the plain form in body copy; keep the §6 term available wherever a reader might need to verify the claim.

Two subtleties worth carrying into copy, because both have already produced defects in this repository:

• Unmeasured is scoped to the action, not the connection. A host the proxy does not intercept is still adjudicated at CONNECT by local egress policy, and that connection is recorded. The honest phrasing is “the connection was observed, the payload was not inspected” — not “nothing was observed”.
• An empty audit log is evidence about the observer. It is not evidence that an agent did nothing. Never present a quiet log as a result.
• macOS needs its own sentence, in both directions. It has no kernel-level interception adapter, and saying so is required. But it is also the only platform on which the host-enforcement rung is reachable today, through an opt-in, authorized managed-settings write. Copy that flattens this into “no host enforcement on macOS” is an understatement defect, and it has been fixed once already — do not reintroduce it. State the route; leave the outcome under Provisional.

Rejected wording

Each row was removed from published copy, or considered and refused, for the reason given. The list is short on purpose: it names the patterns that keep recurring, not every sentence ever corrected. The audited per-file record is the AAASM-5528 inventory.

On the constellation identity

AAASM-4084 introduces Argo Navis as a product alias and visual identity. It is a naming and design layer, and it composes with this brief in one direction only: the metaphor may decorate the promise, it may not stand in for it. A page whose first screen explains a constellation before it explains what happens to an agent’s action has not made the promise; it has deferred it. Where the two compete for the same space, the promise wins.

Altitude — how this relates to the company-level description

Horonomy describes Agent Assembly at company altitude as a governance layer for AI agents — permissions, approval checkpoints, and evidence, which decides which tools, domains, and budgets an agent may use, holds risky actions for human review, and records what happened.

That is correct and this brief does not contradict it. The promise on this page sits one layer below: it keeps the same three ideas — permissions, approval, evidence — and adds the two things a product page must carry that a company page need not, namely when the decision happens (before the action) and where it applies (the paths you route through it). Do not “simplify” a product page back up to company altitude; the boundary clause is what makes it a product claim rather than a category description.

Claim-to-evidence mapping

Every material statement above traces to a merged, re-verified source. E1–E7 are the evidence blocks in the AAASM-5528 inventory; §n refers to ADR 0033.

Provisional

Not asserted in public copy until the owning work lands. Each is here because it is plausible and unverified, which is exactly the category that produces an overstatement.

Using this on a page

For the homepage rewrite (AAASM-5585) and the Product / How It Works rewrite (AAASM-5586), and for any page that makes a product claim:

1. Quote the promise, do not paraphrase it. A paraphrase is a new claim. If the layout needs a shorter line, use the headline — and put the subheadline with it.
2. Keep the boundary clause above the fold. Not a footnote, not a tooltip, not a “learn more”.
3. Pick a §6 term for every verb. If the sentence works with “protects”, “enforces” or “catches”, it is not yet specific enough to publish.
4. Name the mechanism that delivers the guarantee. The right guarantee attributed to the wrong component is its own defect class, and it is the one a technical evaluator notices first.
5. State the default. A capability that exists but is off is a different product from one that is on. The Level 3 table is the reference.
6. Check the direction of the error both ways. Understatement is also a defect — approval holds, pre-dial refusal, the SSRF guard and chain verification all ship, and a page that hedges them away is as wrong as one that overstates.

Last reviewed: 2026-08-06 — AI Agent Assembly Team

Last updated: 2026-08-13 by AI Agent Assembly Team