Build your SecOps, trading, bidding, monitoring or integration agent. Your CISO, chief compliance officer, CMO, COO or CTO can approve it. Build your
SecOps agent.
Your CISO can approve it.

AgentLM is A3T’s agent model. It runs on a single GPU inside your tenant, reads agent memory directly, and works inside your workflows and policies. Every request starts at a gate where AgentLM decides whether it can solve the request, how much thinking it needs, or whether to escalate to a frontier LLM. Its answer is a workflow that has been checked before it runs.

How it works

1. Solve-or-escalate gate. The model’s first layers estimate whether it can solve the request, which skills it needs and how much to think. If agent memory has no matching procedure, evidence or concept, it escalates regardless. A request it keeps costs nothing extra; one it escalates costs a fraction of one pass.
2. Reads memory directly. Knowledge-graph nodes are precomputed into attention blocks stored in agent memory. AgentLM attends to them instead of pasting text into a prompt.
3. Fixed-size sessions. A session is a fixed-size state plus a short window of recent text, saved to memory after every turn and restored on the next. Each turn processes only its new tokens.
4. Answers are workflows. Output is constrained to the CNCF Serverless Workflow schema and dry-run in A3T before it is returned.
5. Learns from outcomes. Verified outcomes and workflow changes are written back to memory. A background job consolidates episodes into knowledge for the next request.
6. Skills without retraining. Domain and tenant skills are small adapters stored in memory and paged onto the GPU when the gate asks for them. A new domain means training one adapter, not a new model.

Early access covers the core model, memory attention and the solve-or-escalate gate. Skill adapters and trained thinking budgets are on the roadmap.

Workflows are written in the open CNCF Serverless Workflow spec and run on a Rust runtime with microsecond dispatch. Inputs are typed, every step is checkpointed, and the execution path is monitored. Only deviations from it go to a model: AgentLM first, a frontier LLM only if AgentLM escalates.

How it works

1. Typed inputs. Every workflow declares its input schema, so bad input is caught at the edge instead of halfway through a run.
2. 26 task types. Agent, model, MCP tool, human approval, switch, loop, transform, emit and more. Routine steps never spend a token.
3. Triggers and sandboxes. Start flows from webhooks, schedules and events, and run tasks in isolated or shared sandboxes.
4. Checkpoint and resume. State is saved after every task. A failed or restarted run resumes at the failed step without repeating side effects.
5. Monitored execution. Each run is compared with the expected path and recorded as an execution graph in agent memory. That graph is what AgentLM reads to handle a deviation and propose a change.
6. Versioned changes. A proposed change becomes a new workflow version once it is approved. The same YAML is on the canvas and in Git.

document:
  dsl: '1.0.0'
  namespace: secops
  name: contain-host
input:
  schema: alert.v2
do:
  - triage:
      call: a3t:agent
      with:
        message: ${ .alert }

Agent memory is one store for everything an agent knows: five memory types, a knowledge graph, and the sessions and attention blocks AgentLM reads directly. It is queried with AQL, the Agent Query Language, and every recall and write is checked against policy.

How it works

1. Five memory types. Working, episodic, semantic, procedural and tool memory. Proven procedures are reused, so agents stop asking a model for what they already know.
2. AQL. RECALL, STORE, LINK and FORGET. Queries read like what the agent wants to know.
3. Knowledge graph. LINK connects memories into a graph agents can traverse, not just a pile of vectors.
4. Model memory. AgentLM’s sessions and attention blocks live here too. On a model upgrade they are recomputed from the source data.
5. Scopes and sharing. Namespaces keep agents and tenants apart; shared scopes let a team’s agents learn from each other.
6. Retention and a real forget. TTLs, history when facts change, and FORGET that actually removes data.

RECALL FROM EPISODIC
  WHERE host = "lt-4471"
  FOLLOW LINKS TYPE "resolved_by"
    INTO PROCEDURAL
  RETURN pattern, confidence

A Cedar policy engine built into the runtime decides every action before it runs: each task, tool call, memory read and write, and every escalation to a frontier LLM. Agents have their own identities, act on behalf of users, and anything not explicitly allowed is denied.

How it works

1. Agents are principals. Each agent has its own service identity, owned by a team, 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 every decision. Agents never see more than the user they act for.
3. Deny by default. Anything not allowed is denied, and forbid always wins.
4. Escalation is an action. Sending data to a frontier LLM is checked like a tool call, by agent, user and data classification.
5. Decision records and dry runs. Every allow and deny is logged with the policy that decided it, and any decision can be dry-run before you ship a change.
6. Your identity provider, your secrets. Keycloak, Entra ID or any OIDC provider, with SCIM sync for users and groups. Secrets are resolved at call time and never handed to a model.

forbid (
  principal,
  action == Action::"llm:escalate",
  resource
) when {
  context.data.class == "restricted"
};