Frequently asked questions

How A3T helps

Every request starts at AgentLM’s gate. The first layers of the model read the request and decide: answer directly, think first, or escalate. If agent memory has no procedure, evidence or concept that matches, it escalates no matter what the model thinks. Because the gate is the model’s own first layers, a request it keeps costs nothing extra, and one it escalates costs a fraction of a single pass.

1. Gate first. Small heads on the early layers estimate whether AgentLM can solve the request, which skills it needs and how much thinking it deserves.
2. Memory coverage is a hard veto. No matching knowledge in agent memory means escalate. The model can’t talk itself into a guess.
3. Solve locally. Kept requests continue through the same pass on a GPU in your tenant. No per-token bill from a third party.
4. Escalate with context. When it escalates, the frontier LLM gets the request plus the context AgentLM gathered, and the answer comes back through the same checks.

What changesFrontier spend tracks the hard cases, not total traffic. The escalation threshold starts high and comes down only as measured accuracy allows.

How A3T helps

AgentLM doesn’t re-read the conversation each turn. A session is a fixed-size state plus a short window of recent text, saved to agent memory after every turn and restored on the next. Knowledge isn’t pasted into the prompt either: AgentLM attends to memory directly, using attention blocks precomputed from the knowledge graph.

1. Fixed-size session state. Most of AgentLM’s layers keep a fixed-size state instead of a growing cache. The session costs the same on turn 500 as on turn 5.
2. Recent text, exactly. A sliding window keeps the last few thousand tokens verbatim, for exact recall of what was just said.
3. Memory as attention, not prompt. Knowledge-graph nodes are precomputed into attention blocks stored in agent memory. AgentLM attends to the ones it needs.
4. Saved every turn. The session snapshot is written back to memory, so a session survives restarts and can move between GPUs.

What changesEach turn processes only its new tokens. Long sessions stop getting slower and more expensive.

How A3T helps

AgentLM doesn’t need knowledge pasted into its prompt. The knowledge graph in agent memory is precomputed into attention blocks that the model reads directly through dedicated memory-attention layers. The prompt stays short, and the knowledge is part of the same pass.

1. Precomputed once. Knowledge-graph nodes — cases, procedures, concepts — are turned into attention blocks for this model and stored next to the source records in agent memory.
2. Selected by the gate. The gate picks the part of the graph that matters for this request, so only relevant blocks are loaded.
3. Attended, not pasted. Memory-attention layers read those blocks directly. The prompt stays short and the question keeps its place.
4. Source stays the truth. Records and the graph remain the source of truth; blocks are recomputed when the data or the model changes.

What changesNo chunking pipeline to tune and no context window to ration. The model works from the same knowledge your agents store.

How A3T helps

AgentLM answers with a workflow, not prose. Decoding is constrained by the CNCF Serverless Workflow schema, so every token keeps the output valid, and A3T dry-runs the workflow before returning it. What you receive is something you can inspect, approve and run.

1. Schema-constrained decoding. The model can only emit tokens that keep the output a valid workflow. No parsing, no repair loop.
2. Dry run before return. A3T checks the workflow against its inputs, tools and policies without side effects.
3. Reviewable. The result is YAML you can read on the canvas and diff in Git, like any other workflow.
4. Same runtime. Once approved, it runs with checkpoints, policy checks and audit, like a hand-written flow.

What changesAgent output stops being a string to interpret and becomes a checked plan you can run.

How A3T helps

AgentLM doesn’t answer from nowhere. Before it commits, the gate checks whether agent memory holds a matching procedure, evidence or concept. If nothing matches, it escalates, whatever the model itself thinks. It can also escalate mid-thought when a step needs knowledge it doesn’t have.

1. Coverage check first. The gate looks for near-matching procedures, evidence and concepts in memory for this request.
2. Hard veto. No coverage means escalate. The model’s own confidence can’t override it.
3. Escalate mid-thought. While reasoning, AgentLM can call escalation as a tool when a step needs knowledge it doesn’t have.
4. A threshold you control. The escalation threshold starts high and comes down only as measured accuracy allows.

What changesAnswers are grounded in what your memory actually holds, and gaps show up as escalations you can see instead of confident guesses.

How A3T helps

AgentLM runs on a GPU inside your tenant, so most requests are answered without any data leaving it. Escalation to a frontier LLM is an action like any other: Cedar decides whether it may happen and what may be sent, and every escalation is recorded with what was sent and why.

1. Local by default. AgentLM, agent memory and the session state all live in your tenant.
2. Escalation is an action. The llm:escalate action is checked like a tool call: by agent, by user, by data classification.
3. Forbid what must stay. A forbid policy can keep restricted data local whatever the model decides; AgentLM then answers or hands over to a person.
4. Recorded. Each escalation is stored as a decision record next to the run: who, what was sent, which policy allowed it.

What changesYou decide what may leave, per agent and per data class, and you can prove what did.

How A3T helps

Every AgentLM answer is tied to the run that produced it. A3T records which memory the model read, whether the gate kept the request or escalated it and why, what was sent if it escalated, and the workflow that resulted. All of it sits in the execution graph next to the policy decisions.

1. Memory read. The memory loaded for the request is recorded with the run.
2. Gate decision. Kept or escalated, with the coverage result that decided it.
3. Escalation record. What was sent, to which model, and which policy allowed it.
4. One graph. The answer, the workflow it became and every decision sit in the same execution graph, queryable with AQL.

What changesFor any run, you can answer “what did it know, and why did it do that?”

How A3T helps

AgentLM only reads memory the request is allowed to see. Before any attention blocks are loaded, Cedar checks the agent, and the user it acts for, against each memory scope. Blocks from scopes they can’t read are never loaded, so the model can’t draw on them.

1. Scopes on memory. Memory is organised by tenant, team and agent namespace, each covered by policy.
2. Checked before loading. Cedar decides which scopes this agent, acting for this user, may read — before any block reaches the GPU.
3. Nothing to leak. Blocks from denied scopes are never loaded, so they can’t influence the answer.
4. Logged. Every allow and deny for memory access is in the decision log.

What changesThe model never knows more than the person it’s working for.

How A3T helps

AgentLM’s output is a workflow, and a workflow does nothing until it passes A3T’s checks. It is dry-run first, then every step is checked by Cedar as it runs, and steps you mark as sensitive wait for a human approval.

1. A plan, not an action. The model produces a workflow. Nothing touches your systems at this point.
2. Dry run. Inputs, tools and policies are checked without side effects.
3. Policy on every step. Each step is authorized by Cedar as it runs, for this agent and the user it acts for.
4. Human gates. Sensitive steps pause for approval, and every decision is logged.

What changesModel decisions go through the same controls as any other change.

How A3T helps

AgentLM is a 4–8B-parameter model that runs on a single GPU, served by vLLM. Session memory per user is fixed in size, so capacity planning is arithmetic. New domains come as small skill adapters stored in agent memory and paged onto the GPU when the gate asks for them, so teams don’t need their own fine-tuned model.

1. One GPU per model. No cluster of accelerators per tenant. Start with one GPU and add more as traffic grows.
2. Fixed per-session memory. Tens of megabytes per session whatever its length, so a GPU’s capacity is a known number.
3. Skills paged in (roadmap). Domain and tenant skills are adapters trained against one frozen core, cached on the GPU and evicted when cold.
4. Versioned core. The core model changes rarely and deliberately. On an upgrade, memory’s attention blocks are recomputed from the source data as a background job.

What changesLatency and cost you can plan, on hardware you control, without a model per team.

How A3T helps

Most of AgentLM’s layers are recurrent: they keep a fixed-size state instead of a cache that grows with every token. A few attention layers keep a short sliding window for exact recall of recent text. Per session, memory stays at tens of megabytes however long it runs.

1. Fixed-size state. Recurrent layers carry the session forward in constant memory.
2. A short exact window. Attention layers keep only the last few thousand tokens verbatim.
3. Older knowledge lives in memory. Anything outside the window is read from agent memory through memory attention, not held in GPU cache.
4. Capacity is arithmetic. Sessions per GPU is a number you can plan, not one that shrinks as conversations grow.

What changesLong sessions and many concurrent users fit on the GPUs you have.

How A3T helps

After every turn, AgentLM’s session — its fixed-size state, the recent-text window and pointers to the memory it used — is saved to agent memory as a snapshot. The next turn restores it on whichever GPU picks it up.

1. Snapshot every turn. The session is written to agent memory after each answer.
2. Restore anywhere. Any GPU serving the same model version can load it and continue.
3. Survives restarts. A node restart or rescheduling costs one restore, not the conversation.
4. Scale freely. Sessions aren’t pinned, so you can add, drain or replace GPUs without stranding users.

What changesGPU nodes become replaceable. Sessions live in memory, not on a machine.

How A3T helps

An A3T agent is three parts working together: a workflow, AgentLM and memory. The workflow carries the known path with typed inputs and deterministic tasks, and its execution is monitored step by step. Only deviations from that path go to AgentLM, which uses the flow execution graph in agent memory to resolve the case and recommend how the workflow should change. If AgentLM can’t resolve it, it escalates to a frontier LLM, and only if policy allows.

1. Typed inputs. Every workflow declares its input schema. Unexpected input is caught at the edge, not discovered by a model halfway through a run.
2. Deterministic by default. Switches, loops, transforms, MCP tool calls and triggers run as plain tasks on the Rust runtime — no tokens spent, the same result every time.
3. Execution is monitored. Each step is compared with the expected path. When a run leaves it — an unknown branch, a schema mismatch, an outcome out of range — only that deviation is handed to AgentLM.
4. AgentLM manages the flow. AgentLM reads the flow execution graph in agent memory — past runs, the paths they took and how they ended — to handle the case, then recommends a workflow change. Approved, it becomes the next version.
5. Escalate only when stuck. A case AgentLM can’t solve goes to a frontier LLM with the context it needs. Cedar decides whether it may leave your tenant, and the call is recorded.

What changesModel calls shrink to the cases that need judgement, frontier calls shrink further still, and the workflow improves from its own history instead of re-reasoning every run.

How A3T helps

A3T checkpoints workflow state after every task. When a step fails, the run resumes from that step with its state intact; steps that already finished are not repeated.

1. Checkpoint after each task. Inputs, outputs and the run’s position in the flow are saved as it progresses.
2. Per-task failure policy. Each task carries its own retries, backoff and timeout, so one slow dependency doesn’t sink the whole run.
3. Resume, don’t restart. After a failure or a restart, the run picks up at the failed step. A ticket that was already opened, or a message already sent, stays done.

What changesLong jobs survive failures and restarts without duplicate side effects or wasted compute.

How A3T helps

A3T’s core is written in Rust. There is no garbage collector to pause execution, and tasks are dispatched in microseconds, so latency stays predictable as load grows.

1. Any trigger in. Webhooks, schedules and events all feed the same dispatcher.
2. Microsecond dispatch, no GC pauses. No stop-the-world pauses, and async I/O keeps workers busy instead of blocked.
3. LLM off the hot path. Deterministic tasks and tool calls run directly. The LLM is called only on deviations (see the first question), so a slow model doesn’t set your latency.

What changesTight latency budgets — like an RTB bid window — become something you can plan for, not hope for.

How A3T helps

Every A3T agent is defined in the open CNCF Serverless Workflow spec and runs on one runtime. Tools, triggers, policy and memory are registered once and shared by every team.

1. One definition format. Teams write workflows in CNCF Serverless Workflow — an open, portable spec, not a proprietary DSL.
2. One runtime to operate. The same deployment, scaling, logs and upgrade path for every agent.
3. Shared building blocks. MCP tools and triggers are registered once and reused. Policy and memory apply the same way to every team.

What changesYou run one platform instead of a framework zoo, and teams ship faster because the building blocks already exist.

How A3T helps

Every A3T run is a workflow, so every step is recorded: what came in, what memory was recalled, which policy decision was made, which tool ran and what came out. The run is stored as an execution graph in agent memory and can be queried later.

1. Each step recorded. Inputs, outputs and policy decisions are captured per step — not just a final chat transcript.
2. Stored as a graph. Runs are linked to the incidents, entities and decisions they touched.
3. Ask why. Trace an outcome back through the steps and decisions that produced it, with an AQL query.

What changes“Why did the agent do that?” gets a precise answer in minutes, not a forensic project.

How A3T helps

In A3T, a workflow change is a new version, not a live edit. It is reviewed as a diff and promoted only after its owner approves it. Inside a flow, approval steps can pause a run before a sensitive action.

1. Versioned definitions. Every change creates a new version; production keeps running the approved one.
2. Review the diff. Reviewers see exactly what changed — steps, tools, inputs — before it goes live.
3. Approval gate. The owner, or your CISO for sensitive agents, approves the promotion.
4. Human-in-the-loop steps. A flow can pause for a person to approve before a high-impact action.

What changesProduction agents change on purpose, with a record of who approved what.

How A3T helps

A3T gives every agent durable memory across five types — working, episodic, semantic, procedural and tools. Facts survive restarts and redeploys, keep their history when they change, and are recalled by meaning rather than by scrolling back through recent messages.

1. Write as you go. Agents STORE what they learn into the right memory type with AQL.
2. Survives everything. Memory is durable: sessions, restarts and redeploys don’t erase it.
3. Recall by meaning. RECALL finds what is relevant to the current task, not just the latest messages.

What changesBetter continuity, and agents stop asking for — or reconstructing — the same information.

How A3T helps

A3T memory brings these functions together behind one durable data model and one query language, AQL. For typical agent workloads, that is one component to deploy, secure and understand instead of six plus the glue between them.

1. Facts and history. STORE and UPDATE keep current values and how they changed.
2. Recall, relationships, coordination. RECALL by meaning, LINK and FOLLOW for graphs, topics and WATCH for coordination and change.
3. Retention built in. TTL and FORGET replace custom clean-up jobs.

What changesLess custom engineering, fewer components to deploy, and one place to look when something breaks.

How A3T helps

A3T memory is organised by scope and namespace, so each agent or team has its own memory by default. Sharing is explicit: links connect records across scopes, and topics carry the messages agents need to exchange.

1. Own namespace by default. Each agent or team writes into its own scope.
2. Share on purpose. LINK records into a shared scope, or publish to a topic other agents subscribe to.
3. Policy on top. Who can read a shared scope is a Cedar policy, not a convention (see the last Policy question).

What changesA common memory for multi-agent systems, without one undifferentiated conversation history that every agent can see.

How A3T helps

A3T updates facts with history instead of silently overwriting them, expires records with TTLs, and removes data physically with FORGET — not just by hiding it.

1. Updates keep history. You can see what the agent believed, and when that changed.
2. TTL at write time. Records can carry an expiry from the moment they are stored.
3. Real deletion. FORGET removes data physically, for retention rules and erasure requests.

What changesControl over stale facts, and a retention story you can explain to your DPO.

How A3T helps

A3T memory includes ordered topics for agent-to-agent communication and watches that notify you when a query’s result changes.

1. Ordered, restart-safe topics. Consumers keep their position, so an agent that restarts carries on from where it stopped.
2. WATCH a query. Subscribe to a RECALL and get notified when its result changes.
3. No glue services. Coordination lives in the same memory layer as the data it is about.

What changesLess custom queue and event-processing code for reactive, multi-agent workflows.

How A3T helps

A3T can generate embeddings locally and be self-hosted, so recall works without calling an external embedding service. Memory, vectors and the model that makes them stay inside your boundary.

1. Local embeddings. Text is embedded inside your environment.
2. Self-hosted memory. Records and vectors are stored where you run A3T.
3. No mandatory external calls. Recall doesn’t depend on a third-party API being available — or being allowed.
4. Local inference too. AgentLM runs in your tenant, so most requests are answered without any model call leaving it.

What changesMore control over data, fewer external dependencies, and more predictable cost.

How A3T helps

Every A3T agent has its own service identity. Before each task, the Cedar policy engine built into the runtime checks who is acting, on whose behalf, which action and which resource. Anything not explicitly allowed is denied.

1. Agent as a principal. Each agent is a named identity in your policies, separate from the person who built it.
2. On behalf of. When an agent acts for a user, that user’s groups are part of the decision.
3. Checked before it runs. Every task and tool call is evaluated first. Denied actions never execute, and are logged.

What changesLeast privilege for agents, written in policy you can read.

How A3T helps

A3T agents run as service accounts owned by groups, not by individuals. Users and groups sync from your identity provider over SCIM, so when someone leaves, their access — and any delegation to agents — is removed, while production agents keep running.

1. SCIM sync. Users and groups come from your IdP; there is no second user list to maintain.
2. Group-owned service accounts. Agents belong to a team, so ownership survives people changes.
3. Delegation follows the person. Acting on someone’s behalf ends when that person’s access ends.

What changesNo orphaned agents, no lingering access, and no outage when someone moves on.

How A3T helps

Every policy decision in A3T is recorded — principal, action, resource, result and the policy that matched. The policies themselves are Cedar: short, readable rules an auditor can check directly.

1. Decision records. Every allow and deny is logged with its context.
2. Readable policy. Cedar rules state what an agent may do in plain terms.
3. Compare the two. “Allowed” versus “done” is a query, not an investigation.

What changesAudit evidence comes from the system itself, not from screenshots and interviews.

How A3T helps

In A3T, permissions are Cedar policy, outside your agent code. The runtime checks policy before every task and tool call, so your workflow just does the work — and security reviews read one set of policies, not your codebase.

1. No auth code in agents. Tasks call tools; the runtime asks the policy engine first.
2. One place to review. Security reads the policies, not every branch of your code.
3. Change policy, not code. Updating a policy doesn’t need a new build of the agent.

What changesFaster approvals, and fewer security bugs hiding in agent code.

How A3T helps

A3T has pluggable OIDC for sign-in — Keycloak, Microsoft Entra ID, Okta or any standards-compliant provider — plus SCIM for users and groups. You integrate once, and every agent and team uses it.

1. Bring your IdP. Any OIDC provider plugs in.
2. SCIM for users and groups. Group membership drives policy automatically.
3. One integration. New agents inherit identity; nobody wires up auth again.

What changesOne identity integration to own, instead of one per agent.

How A3T helps

Memory reads and writes in A3T go through the same Cedar policy check as actions. Access is scoped by tenant, team and agent, and every read and write is logged.

1. Policy on memory. RECALL and STORE are checked like any other action.
2. Scoped by default. An agent reaches only the scopes its policy allows.
3. Logged. Every memory access leaves a record.

What changesMulti-tenant agents without cross-tenant leaks.