The platform, in depth
The engineering detail behind the control plane: the runtime, the governance model, the graphs it keeps and the security it runs under. Every claim here is something we can show you running.
The model
Four stages with the same record running through all of them, and governance that is a layer under every stage rather than one stage among four.
Compose it in Studio from your knowledge, your tools and your rules — or describe what you need and let the platform assemble it.
It reaches your systems and any LLM, from Slack, Telegram, a live meeting or your own app — and a run survives a restart.
Before anything happens it’s checked against your policy and autonomy limits — or it holds for a human.
Every decision is bound to the record it touched and written to one append-only audit trail — so you can re-derive it later, not just retrieve a log entry.
Studio
Workflows
Fourteen step types — agent runs, tool calls, branches, parallel and for-each, waits for a signal or a human — and a run survives a restart. Revision loops let reviewer agents gate, suggest or escalate, each at its own authority tier.
Connectors
Bring any system over the Model Context Protocol, with no bespoke glue — each connector scoped to the agents allowed to use it.
Knowledge
Keyword and vector search fused, optional re-ranking, per-agent knowledge scoping and per-document access control.
Tools
Knowledge search, artifact emit, evidence attach, ask-a-human, approval requests, graph queries, memory read and write — tenant-scoped by default.
Solution Packs
One manifest bundles agents, workflows, knowledge, tools, connectors and schemas. One call installs it on a tenant; one call removes it.
Platform Assistant
Describe the agent, workflow or Xen you need and the Platform Assistant drafts it — wired to your knowledge, tools and policies — for you to review.
Shield · govern and observe
Most platforms bolt on a single approval switch. aXentic checks every agent action on three independent axes at once — then writes the verdict to the audit trail. Separating them cleanly is what makes governance enforceable instead of aspirational.
Axis 1 · Policy
“May this action happen at all?”
Declarative capability rules, bound per agent and per tool, decide whether an action is permitted — a guardrail that never depends on the model choosing to behave.
Axis 2 · Autonomy
“How much can it do without a human?”
A1–A5 sets the freedom tier — from suggest-only to acts-within-policy — per agent and per capability, with explicit escalation the moment it reaches its limit.
Axis 3 · Obligation
“What duties come attached?”
Typed obligations attach duties to an action — get approval first, produce evidence, record a disclosure, clear a checkpoint — enforced at runtime, with a full waiver lifecycle.
Governance on aXentic isn’t a rules file — it’s a set of runtime engines that plan, enforce, test and remember.
Planning
A plan compiler with six strategies — linear tasks, workflow transitions, tool orchestration, recovery, completion and downgrade adaptation — so governance is decided at every enforcement point.
Obligations
Twelve obligation categories with evidence gates, blocking behaviours and waivers — tracking a duty until it is satisfied, not just whether a gate opened once.
Autonomy cascade
Levels set at the agent, the workflow and the step, and the most restrictive wins — so a sub-step can never exceed its parent.
Impact analysis
Blast-radius queries across seventeen subject types and seven analysis modes, before a change ships.
Scenario harness
Ten scenario types and twenty assertion types — catch policy drift in a test run, before it reaches a live agent.
Execution memory
Ten memory categories and ten pattern types. Agents learn from what happened before — strictly within governance boundaries.
The three graphs
One graph to prove what happened, one to govern the things agents touch, one to reason over your business — joined by a single classification-and-lineage spine that turns any of them into an enforcement signal.
Graph 1 · Audit
“How was this produced?”
Every run, artifact, tool, decision and approval, linked by what produced what. Answer an audit question with full provenance — evidence and citations included — instead of reconstructing it across systems.
Graph 2 · Govern
“What touched this record?”
Governs the business objects agents act on — this claim, this contract, this customer. Classify an instance, validate a write to it, trace everything that touched it.
Graph 3 · Reason
“What’s connected to what?”
The business-domain graph your agents reason over — connected facts, not loose documents, each carrying its sensitivity so a smarter answer never becomes a leak.
The operations the Graph Explorer, the Platform Assistant and the traceability API run over the work graph — sixteen node types and seventeen edge types.
Search
Find any entity by name, type, owner or tag.
Neighbors
Everything directly connected to this entity.
Upstream
What flowed into this output — the provenance chain.
Downstream
Every artifact that built on this one.
Evidence chain
The knowledge that influenced this decision.
Traceability
The full path from input to output.
Summary
A narrative of an entity’s role in the graph.
Health
Drift, orphaned nodes and broken edges.
Shadow-AI discovery
The shadow tool a team wires to your CRM on a corporate card — no ticket, no approval, no registration. Five independent infrastructure signals, correlated, surface it; it is then risk-scored and onboarded into governance.
Network egress
Outbound calls to known LLM API domains, attributed back to a source.
Cloud access
Service accounts holding LLM permissions across AWS, Azure and Google Cloud.
Code pipelines
Repositories importing LLM SDKs — agents found in dev branches before production.
Container images
Images with LLM SDKs baked in — agents shipped quietly inside services.
Billing and cost
LLM-provider spend per cost centre; anomalies become discovery candidates.
Data governance
Six mechanisms that act inside the agent’s run, with knowledge of what the data means — rather than at the network edge, after the fact.
Retention-aware routing
Before a run reaches an external LLM, aXentic checks that provider’s retention posture. A run carrying restricted data to a provider that would keep it — or whose policy is unknown — is held for approval.
Mid-run re-gate
If a tool pulls data mid-run that is more sensitive than the run was cleared for, the action is re-judged before it lands. Data it cannot classify is treated as restricted.
Classification inheritance
Mark one record Restricted and anything derived from it inherits the tier — the most restrictive always wins — so nobody has to hand-tag every downstream record.
One enforcement spine
The three graphs share one classification-and-lineage substrate. What a run has read raises its effective sensitivity, and the next checkpoint gates it.
Runtime obligations
“A human must sign off before this sends” stops being a wiki page. Policies become typed obligations — blocking, timed, evidence-gated — enforced against the live run.
Governed retrieval
With the retrieval gate on, each retrieved entity carries its sensitivity tier, and the egress check reads it before grounded output leaves the boundary.
Why aXentic
Not an agent builder, not a framework, not a dashboard — the governed runtime underneath the agents you build, buy or already have.
Compared with platform agent builders
Builders tied to one vendor’s stack govern the agents built on that stack. aXentic is LLM-agnostic, and Shield governs agents built elsewhere too — including ones nobody registered.
Compared with open-source frameworks
Frameworks give you building blocks. aXentic is the enterprise plane beneath them — tenant isolation, durable execution, the audit graph, policy, SSO. Keep the framework; register the agent.
Compared with governance and observability tools
A dashboard reports on what already happened, and a policy document describes what should. aXentic decides before the action and records the evidence as it happens.
Compared with search assistants
Search assistants retrieve and summarise. aXentic agents retrieve, decide, act, hand off, route to humans and produce auditable artifacts.
FAQ
The operational and technical questions teams ask in diligence.
OpenAI, Anthropic, Google (Gemini and Vertex AI) and Azure OpenAI, plus any OpenAI-compatible endpoint — which covers self-hosted models. Bindings are per agent, so you can swap providers without rewriting agents.
Yes. An agent built in LangGraph, CrewAI or your own framework registers as a runtime behind an HTTP endpoint, and your tools come in over MCP. It then runs under the same policy, autonomy level and audit trail as an agent built in Studio.
Runs survive restarts and failures. A long-running or multi-day workflow resumes where it left off instead of starting over, and a step waiting on a human can wait as long as it needs.
It escalates instead of exceeding. The run pauses at a checkpoint, waits in an approvals inbox with the reason it was held, and resumes exactly where it left off once someone decides.