HOW IT WORKS
One codebase, two operators.
T6X is a platform where every screen is generated from data and doubles as a surface an AI agent can operate, under the same identity, the same permissions, and the same audit trail as the person sitting next to it. Here is how that holds together, layer by layer.
One codebase, two operators
T6X is one platform. You model your data and it generates the working screens over it: grids, forms, dashboards. No development project, no separate frontend to build or maintain.
The turn that matters is this: every generated screen is also the surface an agent operates. The buttons your team clicks are the same actions a governed agent is handed. There is no second integration to build, and no shadow path into your data.
Isolation your auditors can verify
Isolation is not a policy the application promises to apply. It is enforced in the database itself, with row-level security: each request carries its tenant, and the database refuses to return anyone else’s rows.
That means one tenant cannot leak into another by construction. The boundary holds even against an application bug or an agent that goes off script, because it sits one layer below the code.
One identity, enforced everywhere
Sign-on is standard enterprise OIDC, compatible with your identity provider. Every request, from a person or from an agent, carries a signed credential, and roles decide what that identity may see and do.
Crucially, roles gate screens and agent capabilities identically. An agent inherits the permissions of the session it runs under; it can never reach a screen or an action a person in that role could not. Governance is not bolted on around the agent; it is the same authorization your teams already use.
Work that survives failure
Multi-step operations run on a durable engine (built on Temporal , the technology behind some of the largest operational workloads in the industry). A run that fails halfway retries or rolls back cleanly; it never leaves your records half-written.
Automation is versioned: work already in flight keeps running against the version it started with, so publishing a change never disturbs an operation mid-run.
Agents as governed processes
An agent is a governed session with a scoped set of capabilities, not an open connection to your data. Reads flow; writes suspend at a Checkpoint for a plain-language approval a person answers before anything runs.
Every action an agent takes lands in a tamper-evident, per-tenant record with a signed decision receipt, ready for review or audit. Agents are multi-provider ( Anthropic , Kimi , Qwen , GLM ) and you bring your own model agreements: usage bills at your rate, with no markup from us.
Runs where you need it
Start on the managed platform with a free workspace. When your requirements call for it, enterprise deployments run as dedicated infrastructure, in our cloud or entirely inside your own, where your data never leaves your perimeter.
For internal systems that should never touch the public internet, T6X reaches them over zero-trust, outbound-only connections: no VPN, no inbound ports, nothing new exposed.
ARCHITECTURE
The whole picture, end to end.
A data model resolves into working screens. A person and an AI agent arrive at the same governed surface. Every write earns its way past identity, row-level security and a human approval. All of it runs on a cluster you control.
- identity, then tenant binding
- row-level security
- agent writes need approval
- 01
What you build
You model your data. The grids, dashboards and flows over it are generated, not hand built.
- 02
Who operates it
A person and an AI agent arrive at the same governed surface, with the same permissions.
- 03
What guards it
Every write is identity checked and tenant bound, row-level security applies, and an agent write waits for a person.
- 04
What it runs on
Your own cluster: Kubernetes and Helm, Postgres with row-level security, Keycloak and OIDC, Temporal, and microVM isolation for agent code.
Nothing under here is bespoke: row-level security in Postgres, Keycloak and OIDC for identity, Temporal for work that has to survive a restart, Kubernetes and Helm for the deploy. The one place we do not use the ordinary answer is agent execution, which runs behind a microVM boundary rather than a shared kernel.
The same path a human click and an agent tool call both travel. The tenant boundary and RLS sit between the request and any row it can read.
- 01 client jwt + x-tenant-id
grid click · or agent tool call
- 02 gateway single sign-on
verify identity · resolve role
- 03 tenant context x-tenant-id
bind tenant to the request
- 04 row-level security rls policy
the database enforces isolation
- 05 response audited
only this tenant’s rows
READ THE REST
The honest way to run agents in production.
Start free in minutes, or walk the platform with us.