Engineering

Inside the DODIL AI Cloud: One Bucket, Three Planes — On Our Own Hardware

platformarchitectureengineeringsovereign

June 30, 2026

Two years ago we made a bet: AI wouldn't just rewrite the application layer — it would rewrite the infrastructure layer too. Agents don't want a pile of disconnected managed services; they want a computer to run on and a data plane they can reason over. Today a large and growing share of the code inside the frontier labs is itself AI-written. The application layer already moved.

DODIL is our answer at the infrastructure layer: a vertically-integrated AI cloud — storage, tables, vector search, serverless compute, and models — behind one consistent, agent-addressable API, running on our own hardware and our own network. In practice it already serves as the backbone agents offload to: where they keep durable memory and data, where they run large-scale data processing next to that data, and where they reach for the most cost-effective model for the job. This is the engineering tour.

The shape: one bucket, three planes

Most "AI stacks" are three or four clouds stitched together with glue code. DODIL collapses that into three planes and a glue layer, all bucket-scoped and all reachable the same way from the CLI, an SDK, or an agent over MCP:

Plane	Product	What it replaces
Data	DataK3 — objects + SQL/Vector/Graph over one HTAP tables engine, one bucket	S3 + Athena/Redshift + Pinecone/OpenSearch + Neo4j
Compute	Ignite — serverless functions & containers, scale-to-zero	Lambda / Fargate / a FaaS + a container platform
Inference	Models — one OpenAI-compatible endpoint, 50+ models	A model gateway + per-provider SDKs and bills
Glue	Scriptum — typed pipelines & recipes	Step Functions / Airflow / bespoke orchestration

The rest of this post walks each one from an engineering angle, then the part that makes it a cloud rather than a wrapper: the hardware and network underneath.

The backbone agents offload to

A capable agent is small; the work is large. It can't hold a corpus in its context window, and it shouldn't run a frontier model over every row of a dataset. So the useful question is what does an agent hand off, and to what? Today, that's what DODIL is for — three offloads that map onto the three planes:

Durable memory & storage → DataK3. An agent's long-term memory, documents, and datasets live in a bucket, not in the prompt. It writes objects, embeds them into a collection, and recalls by search — so "remember this" and "what did we learn about X" are storage operations, not context bloat. The agent stays small; its memory scales to petabytes.
Large-scale processing, next to the data → DataK3 + Ignite. Instead of streaming millions of files or rows through the model, push the work to where the data sits: typed Scriptum pipelines (OCR, extraction, classification, summarization, embedding) run over ingested files, HTAP SQL does the analytics in place, and massively-parallel Ignite runs custom batch jobs from 0 → 240. The model orchestrates; DODIL does the heavy lifting on the platform.
The right-cost model per job → Models. Large-scale processing lives or dies on token economics — a frontier model on every item is ruinous. With 50+ models behind one OpenAI-compatible endpoint, an agent routes bulk work to a cheap, fast model (embed, classify, extract, transcribe) and reserves an advanced model for the hard reasoning — swapping is a string change, and it's one key, one bill. Finding the cheapest model that's good enough for the batch becomes a first-class move.

The rest of the post is how each plane makes those offloads real.

DataK3 — the data plane

DataK3 is our hero product, and the clearest expression of the thesis: the full RAG stack — and more — in one bucket. One bucket = objects (S3) plus one HTAP tables engine serving three pillars over the same rows — no ETL, no second copy, no engine to enable:

Object storage (S3). Wire-compatible with S3 — swap the endpoint, keep your SDK. This is the cheap, durable "truth" layer.
SQL (HTAP). Serverless SQL in a DuckDB dialect over a Postgres wire — the same rows serve transactional point reads and analytical scans, in place on the bucket. Point psql straight at it.
Vector. pgvector semantic search over those same rows — bring a pgvector driver and run <=> KNN, no separate index to keep in sync.
Graph. Cypher over Bolt across the same rows too — traverse relationships with a Neo4j driver or the built-in graph_*() functions, no third datastore.

The reason this matters isn't feature count; it's the three-system desynchronization problem. In a stitched stack, an object, its embedding, and its metadata row live in three datastores kept in sync by pipeline glue that drifts. In DataK3 they're one copy: a row you write is immediately a SQL row, a vector-search candidate, and a graph node. The pattern every DataK3 workload uses is the same — narrow with SQL → rank with Vector → resolve with S3 (and relate with Graph) — one engine, one auth context, one bucket. (Our tutorials build exactly this, end to end.)

Ignite — the compute plane

The premise: every agent needs a computer. Tool-calling — tool → wait → tool → wait — is a chatty round-trip loop. A real agent task is one program, one run, one result. Ignite is where that program runs.

Any way in. Deploy from an SDK, a Dockerfile, no Dockerfile, a BYO image, or straight from GitHub. Python, Rust, Go, Deno — any container.
Scale-to-zero, fast. Pods spin up from zero on the first request and vanish when idle, with ~200 ms cold starts — an order of magnitude below typical FaaS — and autoscale from 0 to hundreds of concurrent executions.
A live URL in milliseconds, with live logs and metrics: dodil ignite deploy ./fn.
Agent-native. Deployed functions are exposed as MCP tools, so an agent calls your code the same way it calls DataK3 — massively parallel, no bespoke glue.

That last point is the connective tissue of the whole platform: compute isn't a separate island, it's another set of tools an agent can reach.

Models — the inference plane

Models is a directory of models behind one API. It's an OpenAI-compatible drop-in — POST /v1/chat/completions, no rewrite — spanning chat, embeddings, rerank, transcription, and raw inference across 50+ hosted models plus bring-your-own.

Swap any model, keep your code. Change a string, not an SDK.
One key, one bill. No per-provider credential sprawl or invoice reconciliation.
Self-hosted or frontier, served from the same endpoint — which, because it runs on our own hardware (below), means your prompts and embeddings don't leave the platform.

DataK3's embedding path leans on this: when a document-rag collection auto-embeds an object on ingest, or data vsearch embeds a query on the fly, that's just Models, invoked internally.

Scriptum — the glue

Primitives are only useful if they compose. Scriptum is the typed pipeline layer that wires them together — and it's what powers the recipes you may have seen in the tutorials. recipe install document-rag deterministically provisions a template-driven collection and an ingest rule in the right order; under the hood that's a Scriptum-authored pipeline. Typed inputs and outputs mean the glue is checked, not stringly-typed shell.

The foundation: our own hardware, our own network

Here's the part that makes DODIL a cloud and not a reseller. The three planes run on infrastructure we own and operate — sovereign infrastructure, built for EMEA. That's a deliberate engineering choice with concrete consequences:

Data residency by construction. Objects, embeddings, tables, prompts, and model weights stay on our hardware, in-region. For EMEA teams with sovereignty requirements, that isn't a config flag — it's the substrate.
The network is ours. Storage, compute, and inference sit on the same fabric, so the narrow → rank → resolve loop and the agent → function → DataK3 path don't traverse three vendors' egress. No cross-cloud egress bills, and latency we control end to end.
Vertical integration compounds. Owning the metal lets us co-design the layers — a vector index that talks to local model GPUs, compute that shares a fabric with storage — rather than papering over hyperscaler boundaries. It's a moat that compounds: every layer we integrate makes the next one cheaper and faster.

Reselling someone else's cloud would have been faster to stand up. It would also have capped how tight the integration could get, and handed the sovereignty story to the underlying provider. We took the harder path on purpose.

Agent-native, all the way down

Pull the threads together and a pattern emerges: every capability is addressable the same way. A bucket, a table, a vector search, a deployed function, a model call — each is a CLI command, an SDK call, and an MCP tool. So a workflow you'd script in bash, you can equally just ask an agent to do, and it orchestrates the same primitives. That's why our tutorials show every step twice — the CLI and the agent are two front-ends to one platform.

That's DODIL: one bucket-scoped data plane, a real computer for your code, a model directory behind one API, typed glue between them — on hardware and a network we own.

Read next:

Tutorials — build real workloads on DataK3 (research agent, e-commerce search, SIEM, and more), with the CLI or by prompting an agent.
AI Research Agent — the narrow → rank → resolve loop, end to end.