Architecture - e6data Docs

Logical view

AgentFlow logical architecture. The customer's durable storage at the top, users and event sources on the left, the AgentFlow runtime in the center, external AI models on the right, and the e6data query engine and outbound delivery at the bottom. — AgentFlow logical view: components and responsibilities. Purple: workflow and model control path. Grey: data, audit and integration paths.

An AgentFlow deployment has a central runtime and four areas around it:

Area	What it holds
Your durable storage (top)	Versioned workflow specs, skill library, Agent Tools, trigger configs, project and catalog memory, semantic ontology, metric definitions, run history, action audit log, schema indexes and source data tables
Your users and event sources (left)	Internal and external users through the browser UI, HTTP API and SSE; external systems such as ERP, MES and CMMS through webhooks
AgentFlow runtime (center)	Interface layer, workflow compiler, per-step scoped agents, subagent runtime, trigger handling, action engine, memory and checkpoints, tool catalog, skill library, semantic layer, code sandbox, observability
External AI models (right)	Provider-agnostic model API, called only from the default worker runtime
e6data stack and outbound delivery (bottom)	The e6data query engine runs SQL on Iceberg, Parquet and Delta tables in your object storage; Slack, email and ERP, MES or CMMS receive notifications, approvals and write-backs

Your IP (workflows, skills, context and audit history) stays in the deployment’s configured storage.

Physical view

AgentFlow physical architecture. Kubernetes CronJobs and clients call the API gateway, which sends tasks through HAProxy to worker and sandbox pods; workers call AI models; pods use Redis and durable storage. — AgentFlow physical view: processes, services and stores.

The runtime is a Kubernetes-native deployment:

Component	Role
API gateway (FastAPI)	Authentication, request routing, task submission, and SSE streaming back to clients. HTTP 8000, gRPC 50051.
HAProxy	Load-balances task submissions to worker pods.
Worker pods	Run the LangGraph agent runtime with an in-memory multiprocessing priority queue. Five lanes: chat and interactive SQL, trigger-started work, Python execution, semantic-layer and metric work, and indexing. No external task broker.
Sandbox pods	Isolate Python execution and validation. They get no application credentials, IRSA credentials or internal service token. Production images can add an `nsjail` boundary.
Kubernetes CronJobs	One per enabled cron trigger. Webhook and manual runs enter through the API.
Redis	Live coordination: task assignments, event streams, checkpoints, locks and caches.
Durable storage	Product state and history. S3-compatible storage or Azure Blob Storage; PostgreSQL for product storage in supported deployments. GCS is supported for telemetry delivery only.

LLM calls come only from the default worker pods. The same picture deploys onto hosted infrastructure, your cloud or VPC, sovereign or private clouds, and on-premises Kubernetes. See Deployment models.

Last modified on October 1, 2026