Embedded mode
Inside your product, invisible to your users
Embedded mode is Zahen with the front end removed. Your backend calls an API; your product keeps every screen, including the one where a person approves what an agent proposed. No second login, no widget, no branding of ours anywhere a customer can see.
What is deliberately missing
No console. No user records. No tenant administration. No interface of any kind. That absence is the product.
Your application already knows who your users are and what each of them may do. Duplicating that inside a second system is how integrations rot — two sources of truth about permissions, drifting apart until someone gets access they should not have. So we do not ask for a copy.
Instead your backend states who is asking, signed, on every call. The division is one sentence: your product decides who may do what; Zahen makes sure the agent only does that, and proves it.
Division of responsibility
Who owns what, with nothing in the middle
-
Your product owns
Tenants, users, roles and sign-in. Your data, and what each user may do with it. The whole experience, including where people review and approve. Which runs start, and when.
-
Zahen owns
Running the agent under the policy you signed. Pausing for approval, and refusing to act without one. Keeping one tenant's data out of another tenant's run. An append-only record of every step, decision and call back into your systems.
The integration contract
Six seams, and nothing else to build
-
1 · Machine authentication
Your backend signs a short-lived workload token for every call. No end-user token ever reaches Zahen, and a call from a browser is refused outright — only your server talks to us.
-
2 · Signed execution context
A run starts from an envelope you sign: the tenant, the requester, the workflow, and a typed scope of exactly what this run may touch. One envelope starts one run, and a replayed envelope is rejected.
-
3 · Run lifecycle
Start, read, list and cancel runs. Retries carry an idempotency key, so a network timeout never results in the work happening twice.
-
4 · Human approval
Zahen hands your backend the exact draft it intends to act on, with a hash of it. Your interface collects the decision; you return it signed. Zahen enforces that the approver is not the person who started the run.
-
5 · Tool Gateway
When an agent needs data or an action, Zahen calls an endpoint in your application, which re-authorizes the named requester against live data before answering or acting. We never hold your credentials.
-
6 · Status and audit
Your backend reads run status and results, and can pull the full audit trail for any run: every retrieval, every proposal, every decision, every call back into your systems.
How it goes
A co-build, not a download
- 01
Scope one workflow
We pick a single workflow where an agent adds real value and a wrong action would actually matter. That is where governance earns its keep, and where a pilot proves something.
- 02
Get a private instance
Your team develops against its own Zahen instance, configured with the same rules as production, without touching anything live.
- 03
Implement the seams
Your backend gets the signing, the approval callback and the Tool Gateway. You get a working reference implementation to read, and our engineers alongside yours while you build it.
- 04
Verify before go-live
A conformance checker probes your endpoints against the contract and reports what is wrong, so the contract is proven before a customer ever meets it.
- 05
Pilot, then widen
Go live on that one workflow with the approval gate on. Widen the scope once the audit trail shows you what the agent actually does in the wild.
Deployment and commercial shape
Isolation is a setting, not a rebuild. One shared instance can serve all of your customers, or a customer whose contract or regulator demands it can have a dedicated instance of their own. Secrets are scoped to the tenant that owns them either way, and a tenant can be purged — leaving a tombstone, so the deletion is itself auditable.
It is an OEM arrangement, not a self-serve subscription. A per-deployment license plus a usage component, sold as a co-built enablement engagement. We are on the integration with you, deliberately: the first one sets the pattern every one after it follows.
You get engineers who have built it, not a support queue. The seams are a small surface but an unfamiliar one — request signing, an approval flow that suspends and resumes, and an endpoint that re-authorizes on our behalf. We build the first one alongside your team, so the pattern is right before you repeat it.
Talk to the team that built it
Bring the workflow you would not let an unsupervised agent near. That is the one worth governing first.