Skip to content

OPERATE · AGENTS & GOVERNANCE

Agents that work your screens, not around them.

Bind an agent to a view and it gets that view’s own actions as its tools. Its writes update the open screen exactly like a human click, and every one of them pauses for a person and lands in a signed, hash-chained record.

SAME-SURFACE TRUTH

The agent edits the screen you are watching.

An agent bound to a view gets the view’s own actions as its tool set: the same buttons a person clicks. There is no shadow API, no second integration to keep in sync.

When it writes, the open grid patches in place through the exact path a human click takes. What you watch is what happened.

orders · grid
Acme, S.A. Approved
Globex Approved
Initech Pending

view-sync · patched in place

bindings

BINDING · orders view

allow catalogue base
allow order__update
allow order__export
deny user__delete
FOCUS LOCK · order #4812

SCOPED BY CONSTRUCTION

It can reach exactly what you bound it to, and nothing else.

Per-view binding sets the agent’s effective surface: allow and deny lists, a prompt extension, attached skills, and MCP tools, always intersected with the role’s own permissions.

Focus Lock pins an agent to a single record. Addressing another one is not forbidden by policy; it is structurally impossible.

THE CHECKPOINT

Reads flow. Writes wait for a person.

Reads run freely; every write suspends into a Checkpoint: an approval card that explains, in plain business language, what the agent is about to do. Approve once, or approve for the session.

In plan mode the write tools are literally absent from the model’s reach until a human approves “Begin implementation.” It cannot act early because it has nothing to act with.

orders-ops-agent
In session
claude-code
Prepare today’s order summary and update the board.
On it. I’ll pull today’s orders, prepare the summary, then update the board.
Done. The board now shows 42 orders ($12,480) and the shift summary is posted.
Message the agent…

Plan mode · write tools absent until “Begin implementation”

INVOCATION LOG
tenant chain · exportable
tooloutcomehash
order__update allowed 9f0a3…
user__create approved 9f1a3…
user__delete blocked 9f2a3…
Export · JSON / CSV
SIGNED · SHA-256 CHAIN

THE RECORD

Every action on the record, filtered and exportable.

Each tool call the agent makes is one row: the tool, its outcome, a trace id, and a signed decision receipt, linked into a per-tenant SHA-256 hash chain.

Filter to a single blocked call, expand the receipt-backed payload, and export the slice to JSON or CSV.

PROVIDERS & EVALS

Run any model. Grade it before it ships.

Run kimi, qwen, GLM, or claude-code: provider and model live on the session, switchable from the chat. Keys are vault-first, never baked into the surface.

Grade agents against a rubric in a live observer: the Verdict streams in with a score, per-criterion checklist, and gate badges.

20 eval gate groups. Graded before they ship.

EVAL OBSERVER
live
kimiqwenGLMclaude-code

Verdict

92 / 100

G1G5G13G20

GOVERNED BY CONSTRUCTION

Governance is not a layer you add. It is the path the agent acts through.

Stop by default

Writes suspend into a Checkpoint with a business explanation. Nothing runs without an answer.

Human in the loop.

Safety floor

Cross-tenant and cross-record arguments are hard-denied before any approval is even offered.

Hard deny.

Chained and signed

Every invocation is a row with a signed decision receipt in a per-tenant hash chain.

Tamper-evident.

One surface. Two operators. Every write on the record.

The screen your team builds is the screen the agent operates: governed, explained, and signed. See the Checkpoint live.