You build the product.
Own the domain choices, user experience, frontend, differentiated logic, and the details customers actually notice.
For developers and coding agents
Describe the operation. Publish it to the runtime.
Give Codex a business use case and let it work through the DataInbox CLI. Every Inbox becomes an interactive database and rule-based graph for your data and content, with a standard OpenAPI specification for any application, AI system, agent framework, or user interface. Define and change business interactions and rules directly at runtime.
Codex · Customer experienceCLI active
DataInbox CLI
doctor agent-config
config validate
diff · 4 changes
dry-run passed
tests · 4/4
stored config verified
Why developers care
Stop scattering every useful idea across another invisible stack.
A useful application usually needs far more than a screen: ingestion, schemas, storage, state, rules, permissions, integrations, agents, retries, evidence, and APIs. Without one runtime, those concerns become separate edge functions, backend services, databases, and deployment targets. DataInbox lets Codex operate them as one declarative environment through the CLI.
DataInbox runs the operation.
Receive events, organise context, apply rules, bound agents, perform actions, expose data, and preserve evidence.
Built since 2014
A match more than a decade in the making.
Since 2014, we have been developing a declarative runtime for compliant, privacy-by-design data processing services. We built it so data and business operations could be described explicitly, changed safely, and executed without rebuilding the underlying technology stack for every use case.
AI agents turned out to be the interaction layer this runtime was made for, even if we did not anticipate them in 2014. Codex can understand an intention and translate it into configuration. DataInbox can validate, challenge, publish, and operate that configuration. The combination turns conversation into working software without making the model itself the production runtime.
AI understands
Intent, domain language, exceptions, and the desired outcome.
CLI challenges
Readiness, validation, diff, dry-run, and explicit publication.
Runtime operates
Events, state, data, rules, actions, access, and evidence.
From Codex to a production-safe publication
One instruction becomes a challengeable, published operation.
Start with the outcome, not a technical specification: “We want to improve customer experience using our inventory and order data.” Codex first discovers the customer moment, authoritative sources, access boundary and permitted actions. DataInbox then turns those answers into an event-driven operating model instead of another disposable prototype.
- 01
Describe the operation
Tell Codex the event, data, rules, people, systems, agents, and outcome you need in ordinary language.
- 02
Author the Inbox
Codex translates the use case into configuration, schemas, paths, mappings, rules, tools, and actions.
- 03
Challenge and publish
The CLI checks readiness, validates the file, shows the exact diff, dry-runs it, and publishes the reviewed configuration.
- 04
Operate immediately
The Inbox can receive events, structure data and content, resolve context, enforce rules, and perform permitted actions.
- 05
Connect any experience
Use the Inbox through its standard OpenAPI specification from any development project, AI system, agent framework, or user interface.
Safe CLI publish flow
datainbox --format json doctor agent-config
datainbox --format json inbox config validate --file app.yaml
datainbox inbox config diff <inbox-id> --file app.yaml
datainbox --format json inbox config set <inbox-id> --file app.yaml --validate --dry-run
datainbox --format json inbox config set <inbox-id> --file app.yaml --validateThe AI-operable runtime
The combinations live in one operating model.
Compose the sources, paths, rules, agents, tools, approvals, and outcomes the use case requires. They remain inspectable as one configuration instead of disappearing across a collection of services.
Events and ingestion
Receive messages from frontends, APIs, webhooks, systems, files, databases, devices, and agents.
Logical data and content
Store operational records, projections, documents, and knowledge in paths that fit the domain.
Rules and mappings
Validate, transform, route, merge, classify, approve, block, or escalate from configuration.
Agents and tools
Give agents only the context, lookups, models, limits, and capabilities required for their task.
Actions and outcomes
Call approved APIs, notify people, update systems, or create the next traceable business event.
OpenAPI and evidence
Every Inbox exposes a standard OpenAPI specification while decisions, state changes, tool calls, and results remain inspectable.
Interface freedom
Every Inbox is ready for any interface.
Every Inbox exposes a standard OpenAPI specification and can serve your development project as an interactive database or as a rule-based graph for any type of data and content. Applications, AI systems, and agent frameworks can use it through the interface of your choice, while you define and change business interactions, permissions, and rules directly at runtime.
Any interface
Apps, agents and AI systems
Standard OpenAPI
Data, content and actions
Your runtime rules
Interactions, access and evidence
Developer FAQ
Practical boundaries before you start.
Does DataInbox replace every backend system?
No. DataInbox provides the event, context, rule, action, agent, and evidence runtime for the operation you model. Existing ERP, CRM, product, payment, and specialist systems can remain authoritative and participate through governed connections.
Can Codex change a production Inbox directly?
Only with the identity and authority you provide. The intended configuration flow is explicit: readiness check, validation, diff, validated dry-run, then apply. A coding agent does not need an unreviewed shortcut into production.
Where do application data and content go?
An Inbox can organise operational data, projections, documents, and knowledge in logical domain paths. Rules can validate, map, merge, route, and expose only the records and fields needed by the operation.
Can we keep our own frontend?
Yes. Every Inbox exposes a standard OpenAPI specification, so you can use any frontend, development framework, agent framework, hosting platform, or design system. Each interface operates within the identity, access, data, action, and rule boundaries you define at runtime.
Do we still need separate edge functions and databases?
Not for runtime concerns already modelled inside the Inbox. Data, content, state, mappings, rules, agents, actions, and evidence can live together instead of being spread across feature-specific edge functions, servers, and databases. Specialist systems can still remain authoritative where the use case requires them.
Why does AI make this possible now?
AI can translate a domain conversation into understandable declarative configuration. The DataInbox runtime can validate and execute that configuration predictably. The model supplies the expressive interaction layer; the runtime supplies operational truth and control.