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
The platform is a single application — a NestJS backend and a Vue frontend. You model your data, and the platform generates live CRUD screens over it: grids, forms, dashboards, no handwritten frontend required.
The turn that matters is this: every generated screen is also a tool surface. The buttons a human clicks on a grid are literally the tools a bound agent is handed. There is no second integration to build for the agent — the app and the agent operate the exact same surface.
Tenancy at the database
Isolation is not a filter the application remembers to apply — it lives in PostgreSQL row-level security. Each request carries its tenant, and the database itself refuses to return rows that belong to anyone else.
A tenant cannot leak into another by construction. The isolation survives a forgotten WHERE clause, a bug in a resolver, or an agent that goes off-script — because the boundary is enforced one layer below the code.
One identity, enforced everywhere
Authentication is Keycloak OIDC. Every request — from a browser or from an agent — carries a signed JWT, and roles decide what that identity may see and do.
Crucially, roles gate screens and agent tools 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 the UI already runs.
Durable automation
Multi-step work runs on a Temporal -backed flow engine. Flows are versioned snapshots: retries, error envelopes, and saga-style compensation are first-class, so a run that fails halfway does not leave the system in a half-written state.
Because versions are snapshots, a flow that is running keeps running against the definition it started with — you can publish a new version without disturbing work already in flight.
Agents as governed processes
An agent is a session with a scoped tool surface — not an open connection to your data. Reads flow; writes suspend for a plain-language approval a human answers before the action runs. In plan mode, write tools are absent from the model entirely until a person says "begin".
Every tool invocation lands in a per-tenant, hash-chained record with a signed decision receipt. Agents are multi-provider: the claude-code runtime alongside Kimi , Qwen , and GLM — you bring your own model keys.
Ships on Kubernetes
T6X deploys with Helm . Each heavy dependency — Postgres , Keycloak , Redis , RabbitMQ , SeaweedFS , Temporal — is installed as its own cluster-wide operator, so the app deploys as one clean upgrade against services that are already serving.
Run it on your cluster or on ours. For private systems that should never touch the public internet, a zero-trust mesh ( OpenZiti ) reaches them over outbound-only connections — no VPN, no inbound ports.
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 keycloak oidc
verify JWT · resolve role
- 03 tenant context x-tenant-id
bind tenant to the request
- 04 row-level security rls policy
postgres enforces isolation
- 05 response audited
only this tenant’s rows
READ THE REST
The honest way to run agents in production.
Scaffold the whole platform in minutes, or walk the architecture with us.