The model asks for a structured action, not a hidden write.
Agents
Let AI run real operations without giving it a way to go rogue.
Bring your own model. KarmanFlow gives it a governed action surface, approval gates, and receipts your team can replay. The same boundary applies to humans, systems, and agents, so an agent can never take an action a person could not.
Where we are today
What is live, what is in preview, and what is still in design.
We would rather you trust this page than be surprised in the quickstart. Reads and agent identity work today. The governed-write and approval path is on the way, and we say so here before you build.
Read-only agent queriesLive Agents read inventory, orders, receipts, events, and timelines through typed query contracts. No write path, so nothing waits on a policy gate.
Agent identity and scopeLive Install, suspend, resume, and re-scope tenant-bound agents from the kf CLI. Every change emits an event and lands on the same audit trail your operators use.
Scoped writes with loggingPreview Low-risk writes such as reservations run through policy and record the agent identity and the model that produced the call. Available in the preview path.
Approval-bound writesIn design High-risk writes that pause for a named operator before they execute. We would rather ship the approval binding correctly than ship it early.
Broad-impact changesPlanned Billing and platform-shaping work stays human-run by design. An agent can draft the request; a person owns the change.
Agent boundary
A model can propose work. KarmanFlow decides how it moves.
The operating model is simple: agents can assist, prepare, and execute approved actions. Risky work pauses for a person, and broad-impact work remains human-run.
Scope, role, environment, and risk class are checked first.
Approval-bound changes wait for a named operator.
The action, actors, decision, and result remain replayable.
Why agents work safely here
Six things you do not have to bolt on later.
Agents are not a separate surface with looser rules. They use the same approved actions a new operator would, and they leave the same audit trail. If an action is not safe for an agent, it is not safe for anyone.
Same approval boundary your humans use.
Agents call approved actions the same way an operator does. Approval-bound work pauses for a person. Broad-impact work stays human-run.
Every action leaves a replayable receipt.
Each tool call produces a typed receipt with actor, policy decisions, inputs, and outputs. Replay it from the timeline, the CLI, or the API.
Bring your own model.
Claude, OpenAI, Gemini, or your own. The contract is the action surface, not the model. Swap models without changing what an agent is allowed to do.
Extend through declared profiles.
Customer-owned and partner-owned agents declare request classes, tools, risk, data access, handoffs, evals, and kill switches before tenant admins enable them.
No silent writes.
Agents can only use approved KarmanFlow actions. They cannot skip approvals or change data through an untracked path.
Per-actor audit, end to end.
Receipts carry the actor identity through every layer. Customer service can answer 'which agent did this' the same way they answer 'which operator did this'.
Progressive actions, not free-form chat.
The UI surface for agents is a typed action card with confirm and approve states. Operators see what is being proposed before anything moves.
Why not just a copilot
What a governed action surface does that the alternatives cannot.
Most ways to add AI to operations bolt a model onto the side. The difference here is not the model. It is that every agent action runs through the same identity, policy, and receipt your operators do.
A chatbot can answer. It cannot be held to a boundary.
Bolt-on copilots generate text and hand you a suggestion. They carry no identity, no risk class, and no receipt. KarmanFlow agents act through the same approved actions your operators use, so the answer and the action share one audit trail.
Automation without identity is a blind spot.
Scripts and RPA bots write through shared service accounts that policy cannot reason about per actor. A KarmanFlow agent carries its own identity into every receipt, so you answer which agent did this the same way you answer which operator did this.
Every direct write is a new audit gap.
Point-to-point integrations write straight to data and leave governance to each team. KarmanFlow routes every agent action through one policy gate and one receipt format, so there is no second read path for the AI work.
Risk classes and approval boundaries
Four gates in operator language.
Agent actions are grouped by risk. Read-only work can run immediately, low-risk updates are logged, high-risk changes ask for approval, and broad-impact changes stay human-run.
R0: Read-onlyPreview Inventory levels, receipts, events, and order timeline. Agents can answer questions and prepare evidence packs. No write path, so no policy gate is needed.
R1: Scoped writes with loggingPreview Reservations, low-risk inventory adjustments, label drafts. Policy runs synchronously in the preview path. The receipt records the agent identity and the model that produced the call.
R2: Approval-bound writesIn design Bulk write-offs, price overrides, cross-location transfers. Agent proposes the action; the approval surface binds an operator before the command executes. Timeline shows both actors.
R3: Human-run onlyPlanned Broad-impact changes, billing changes, and platform-shaping work should stay outside agent execution. Agents can draft the request, but a person owns the change.
From the team
Bring your own model. We bring the boundary. The same policy gate that says no to a human at 2am says no to an agent at 2am, with the same receipt and the same replay path.The KarmanFlow team
Get started
Ship your first agent action in five steps.
Install the kf CLI, generate an MCP key bound to an agent identity, point your model client at the surface, and run a typed tool call. The receipt comes back to your timeline.