Every agent action looked safe. The workflow wasn't — so I built Arclasp

I put Arclasp into public beta this week after spending the last few months building and testing it. The idea came from a problem that kept bothering me as AI agents moved from answering questions toward actually changing things. Most controls around agents are naturally designed around one action at a time. The agent wants to call a tool, so you check that call. It wants to write to a database, so you check that write. It wants to send an email, so you check the email.

That makes sense until several individually acceptable actions belong to the same workflow. Imagine a procurement workflow involving several agents. A research agent finds suitable vendors and collects pricing. A negotiation agent gets an acceptable quote. A procurement agent records a $2,500 commitment. Later another part of the workflow adds a $3,000 service commitment. Operations adds another $2,000, and eventually the workflow wants to make a $4,000 deposit.

Nothing in that sequence necessarily looks absurd when viewed one call at a time. But the workflow has now accumulated $11,500 of financial exposure. If the actual business boundary was $10,000, then checking every action independently missed the thing that mattered.

That was the starting point for Arclasp.

The workflow is the policy object

Arclasp represents a governed workflow as a Chain. Actions inside that workflow are recorded against the same Chain, which means policy can evaluate accumulated state rather than pretending every event happened in isolation.

When a governed action reaches Arclasp, the backend can return one of four outcomes:

• allow
• allow with a flag
• require human approval
• deny

If the action requires approval, the Chain pauses and waits for the decision before continuing. If it is denied, the governed path stops. The important architectural boundary is that Arclasp does not execute the customer’s tools. The application still owns the real side effect. Arclasp sits around that execution path and decides whether the governed action should be allowed to proceed.

Conceptually, the flow is:

agent proposes an action
        ↓
Arclasp SDK records the governed action
        ↓
Arclasp backend evaluates policy + workflow state
        ↓
allow / flag / require approval / deny
        ↓
customer application executes if permitted
        ↓
workflow continues and governance evidence is preserved

That separation matters to me. I did not want the same probabilistic system proposing an action to also be the final authority deciding whether the action was acceptable. The model can propose. The customer application can execute. The governance decision lives outside both.

What the Python integration looks like

The public SDK is Python and the basic integration is intentionally small.

import arclasp

arclasp.init(api_key="...")

async with arclasp.Chain(
    "vendor-purchase",
    metadata={"purchase_request": "PR-4821"},
) as chain:

    await chain.record_agent_action(
        agent_name="procurement-agent",
        action_type="tool_call",
        action_name="record_commitment",
        payload={
            "amount_usd": 4000,
            "vendor": "example-vendor",
        },
    )

The application tells Arclasp about the meaningful action before the consequential execution happens. Arclasp evaluates it against the relevant governance state and returns the decision to the application. The SDK currently supports direct Python integration as well as LangGraph, LangChain, CrewAI and MCP.

Installation is just:

pip install arclasp

GitHub: https://github.com/TOAAiV/Arclasp

Website: https://arclasp.com

The hosted side contains the policy engine, approvals, Chain state, evidence, verification and the dashboard used to inspect governed workflows.

Why cumulative state changes the problem

Financial exposure is an easy example because the arithmetic makes the problem obvious, but the underlying idea is broader than money.

The question I am interested in is not merely:

Can this agent perform this action?

It is closer to:

Should this action still be permitted given everything this workflow has already done?

That difference becomes important as agents gain more autonomy. A workflow can send multiple external communications. It can make repeated changes to customer state. It can accumulate cost. Several agents can participate in the same task. An action that would be harmless near the beginning of a workflow may not be harmless after twenty other actions have already happened.

The governance system therefore needs memory of the workflow itself. Arclasp currently tracks specific forms of accumulated state and policy context rather than pretending to solve every possible temporal-policy problem. The product is still early, and broader stateful policy expressiveness is an area I expect to keep developing.

Human approval without handing execution to Arclasp

One requirement I had from the beginning was that human approval should not turn Arclasp into an orchestration engine. If policy returns require_approval, the Chain enters a waiting state. A human can review the decision through the approval flow, and the SDK waits for the result. An approval lets the governed workflow continue; denial or timeout stops it.

The customer still controls the actual tool call. That distinction may sounds small, but it avoids a lot of architectural confusion. Arclasp is not trying to become the system that sends your emails, pays your vendors or modifies your database. It is the decision boundary around actions you have chosen to govern. There are also scoped exceptions for cases where repeatedly approving the same narrowly defined action would be pointless. Those exceptions can be time-boxed or single-use rather than becoming permanent blanket bypasses.

Failure behavior was more important than the happy path

Getting an allow response from a policy engine is easy compared with deciding what should happen when the surrounding system behaves badly.

What happens if an event is retried?

What happens if the approval request is submitted twice?

What happens if two requests race?

What happens if a Chain is being completed while another operation is still changing its state?

What happens if the governance backend is unavailable?

Those questions ended up consuming much more engineering time than the basic dashboard or policy rules. Governed execution is intentionally backend-authoritative. If Arclasp cannot obtain a trustworthy decision for a governed action, the public execution path is designed to stop rather than silently convert uncertainty into permission. That is a meaningful tradeoff. Putting an external decision system on a consequential execution path introduces dependency and latency. I do not think that should be hidden behind marketing language.

The point is that for the actions important enough to govern, failing open can defeat the reason the control exists in the first place. I also spent a lot of time on idempotency and state transitions because “the request was retried” should not become “the governance system thinks two different things happened.”

What remains after the decision

Stopping or approving an action is only half of the problem. Months later, someone may want to know what was proposed, what state the workflow was in, what decision Arclasp made, whether a human approved it, and whether the stored governance record has changed since then. That is why Arclasp also has an evidence layer. Completed Chains can produce signed and hash-linked governance records, and those records can later be verified. Approval decisions also preserve signed evidence around the decision that was made.

I am careful about how I describe this because cryptographic language is easy to oversell. A signed governance record does not magically prove that the outside world changed exactly as claimed. If the customer never captured the relevant execution evidence, Arclasp cannot manufacture it afterward. It does not automatically make a workflow legally compliant, and “tamper-evident” is not the same thing as “tamper-proof.”

What the evidence system is intended to preserve is the governance history Arclasp actually observed: the workflow, the decision context, approvals and the integrity of the stored record. For systems where autonomous decisions may later matter to another engineer, an operator, an auditor or a customer, I think that distinction becomes increasingly useful.

What Arclasp is not trying to become

One risk when building in a young category is that every neighboring feature starts looking like part of the product. I have been trying to resist that. Arclasp is not an agent builder. It is not an orchestration framework. It is not trying to replace LangGraph or CrewAI. It is not a general observability platform, an LLM evaluation suite, a universal IAM system or a service that executes every tool on behalf of the customer.

It also does not claim that adding Arclasp makes an AI system compliant with a particular law or guarantees exactly-once execution of an external side effect. The product is narrower: it is runtime governance for workflows where agent actions can have consequences and where the decision should depend on more than the current call.

There are also real limitations in the current public beta. The SDK is Python-first today. The current product is hosted rather than a mature self-hosting offering, and there are enterprise features I have deliberately not pretended are finished. I would rather state those boundaries clearly than make the product sound larger than it is.

Why I am publishing this now

For months, the comfortable question was whether I could make Arclasp technically better. There is always another test to add, another failure case to harden, another policy primitive to build and another competitor to study. That work matters, but eventually it becomes possible to hide inside engineering. The harder question is whether another team will actually put Arclasp in front of a workflow that matters. That is the stage I am at now.

I am looking for teams running agents that can make real changes: money, customer records, databases, production systems, infrastructure, external communications or anything else where an incorrect action has an actual consequence. For the first few teams, I am happy to work directly on the integration rather than pointing people at the documentation and disappearing.

I am especially interested in the objections. Does putting an independent decision boundary in the execution path add too much latency? Is the integration burden larger than the value? Are teams already solving this cleanly inside their applications? Does accumulated workflow state matter in the real systems people are deploying, or is it mainly a problem that looks good in architecture diagrams?

Those answers are more valuable to me now than another month of building in isolation. If you are running agents with real write authority, I would genuinely like to know how you are controlling them today — especially once the risk stops belonging to one tool call and starts belonging to the workflow around it.