Build on the systems that hold your data.
KEZEL combines workflow automation, analytics and project delivery over a shared orchestration runtime. Start with one component. The deployment specification and data-access answers below help your team assess the fit.
What each component does.
Workflows
Run ETL, case workflows and scheduled jobs beside your data. Each step is checked against policy at run time. The orchestration controller handles dispatch and retries; the ledger records the outcome.
agent workflows · ETL · scheduled jobs · run-time policy checks · run ledger
Use for case routing, scheduled refreshes and ETL inside your environment.
Orchestration engine
Zero Trust Orchestration is the runtime shared by the components. It compiles policies into encrypted instructions. Agents pull those instructions, execute beside your data and record each action.
Metadata Engine · Instruction Generator · Vault & Crypto Services · Orchestration Controller · Streaming Agent · Monitoring & Audit Engine
Review the request walkthrough, network direction and deployment requirements with your security team.
Analytics module
VizEngine builds dashboards. LLMCore plans plain-language queries from schema metadata. KEZEL Insights Studio adds forecasting and risk scoring. Partners can read governed views inside your environment under their assigned roles.
VizEngine · LLMCore · Insights Studio · governed views · lineage
Use for dashboards over operational data, forecasting or ranked review queues.
VIA
KEZEL VIA tracks project delivery and the decisions around agent-built work. Tasks can require a spec and approval before proceeding. Run records include cost and provenance. KEZEL Check-in adds team updates, stored with the project records in your deployment's database.
projects · sprints · tasks · delivery modes · spec and approval gates · decisions · attention queue · run provenance · KEZEL Check-in
Use for project tracking, approval queues and team check-ins.
Components share the runtime and policy layer.
Add analytics to a workflow deployment, or use VIA alongside both. The components share Zero Trust Orchestration policies and the orchestration ledger. Your team still reviews the permissions each new workload needs.
The questions your architect will ask.
Open a question to check data access, deployment or integration requirements.
Do we have to adopt the whole platform?
No. KEZEL is a family of pre-engineered components. Start with one workflow or one dashboard; the orchestration engine underneath is the same, so later components attach to what you already run.
Where do AI models and agents fit?
Analytical models and agent workflows run inside the boundary, acting with permission through the orchestration engine, and every action lands on the ledger. LLMCore plans from schema metadata in the control plane and is built to plan without raw-row access. Swap models as they improve; the policy layer stays.
What stays inside our boundary?
Raw records, computed results, and their consumption. Dashboards and APIs are read inside the boundary through the policy gate; no records pool in a second platform.
What actually crosses it?
One thing, inbound: an encrypted instruction built from schema metadata and intent. There is no outbound data path. Dashboards, alerts and APIs are consumed inside the boundary, through the policy gate, and every crossing and read is logged.
What can the control plane see?
Schema and context metadata, plans and run status. It is built to work without raw-row access.
How does the agent deploy?
As a Docker or Kubernetes container, a VM, or a system service your team operates: on-premises, in your cloud, or hybrid. The agent initiates every connection and pulls its instructions, so no inbound ports are required; restricted and air-gapped patterns are a design target.
Which systems does it speak to?
Warehouses (Snowflake, BigQuery, Redshift), SaaS (Salesforce, HubSpot, Zendesk) and custom systems, with CDC and legacy connectors for estates that predate the cloud.
Where does the project record live?
In your deployment's store, as typed records on the graph kernel: projects, tasks, specs, decisions and agent runs, under the organization's SSO and roles. The kernel governs that schema today. Moving it into the execution plane, beside the agent, is on the roadmap and is labelled as such.
What do our auditors get?
The orchestration ledger: question, plan, policy decision, reader, timestamp. Plus lineage from any published figure back to its sources.
What the deployment requires.
Analytics over the existing stores
Queries and models run beside the existing stores. Raw records and computed results remain in your approved environment, where readers access them under policy.
Data stays in its jurisdiction
Deploy the agent in the required jurisdiction. Local execution, lineage and access logs are designed to support residency and governance obligations.
First deployment is a single agent
Your team supplies the compute and operates the agent. The security review covers its policies, credentials, egress destinations and the permissions needed for the first workload.
KEZEL · AGENT SPEC
- deploy
- Docker · Kubernetes · VM · system service
- footprint
- one lightweight agent inside your environment
- transport
- TLS 1.3
- encryption
- AES-256
- secrets
- vault-held keys
- connectors
- Snowflake · BigQuery · Redshift · Salesforce · HubSpot · Zendesk · custom
- audit
- every orchestration step logged
Security documentation and attestation scope: trust.dbtez.com
See KEZEL run a workload like yours.
Tell us which system holds your data and what you need to do with it. We’ll demonstrate on sample data, then scope a pilot with your security team.