Production
What a production agent needs under it
Every production agent sits on a data layer: a database with a real schema, object storage, a full activity log, and reports a person can read. This page walks through each part and why it has to exist before the agent does useful work.
The failure
An agent that builds its own store also guesses.
When an agent creates its own infrastructure on the fly, it also makes guesses about what exists, how records relate, and what a status means. Each guess looks fine in the moment. The agent writes a record, names a field, and moves on.
The guesses pile up. Two records that should link do not. One status means done in one place and pending in another. Later a person opens the store to answer a simple question and finds no straight answer. They spend time to unwind what the agent improvised. That time is the real cost, and it grows with every run.
Meaning
A schema makes the decisions explicit.
We design a database before the agent runs. The schema names the entities, the relationships between them, the grain of each record, and the valid states a record can hold. The agent inherits that structure and writes inside it.
The schema is the first of four parts we run. The others are object storage, logging through the Agent Flight Recorder, and workflows with reports and dashboards. Each part has a clear job, and the agent uses all four over plain HTTP.
We look after migrations and quality rules. When the work changes, we change the schema and move the data. The agent keeps a store that means the same thing today as it did last week.
A place to write
Buckets hold what the schema should not.
Some output does not belong in a row. Reports, exports, and raw payloads go to object storage. The agent writes a file to a bucket and records the reference in the schema.
When someone outside needs a file, we issue a signed link. The link grants one file for a set time. There is no shared login and no open folder to guard.
A tape
The Flight Recorder keeps the record straight.
The Agent Flight Recorder records every session, tool call, model turn, and cron beat against the agent that made it. The record is sequenced, timestamped, and append-only. No run can rewrite what an earlier run wrote.
Prompts and tool output are encrypted before they leave the host. The backend stores ciphertext, and the customer holds the key. We cannot read the content.
We leave the raw record alone. A gap in the tape is itself a finding, so it stays visible. The Flight Recorder page has the event types and the layout.
A report someone will read
Output has to reach a person who acts.
We organize reports and dashboards around decisions, exceptions, and trends. The person who opens one sees what needs a choice, what fell outside the expected range, and where the numbers move over time.
This is the test for the whole stack: if nobody acts on the output, the agent is just a cost. Buckets hold the reports and the exports behind them, and a signed link moves any file to a person outside the account.
How we stand that up
One call, then we run it.
You make one call and tell us what the agents do. We provision the four parts and wire them together. Your agents connect over plain HTTP with scoped credentials. We keep it running as the work changes.
We hold the cloud account, so there is no console for you to learn. We design the backend, run it, and change it when the work changes. You send a note instead of learning a tool. The how it works page has the steps in full.
Proof
This runs in production today.
A cold-chain monitoring fleet uses this stack. It has 906 devices reporting, and it sends weekly fleet condition reports. We manage it end to end. On that fleet a Java service takes the readings, and the agents monitor and report on the record it writes. The cold-chain case has the detail.
Questions
Common questions.
What is agentdbaas?
A managed cloud backend for AI agents. We run the database, object storage, logging, and dashboards. Your agents read and write against it over plain HTTP.
Do I need to learn a console?
No. We hold the cloud account and hand your agents scoped credentials.
How do agents connect?
Each agent connects over plain HTTP with its own scoped credentials. It works with the framework you already use.
What happens when the schema needs to change?
We change the schema and migrate the data. The agent keeps writing against a store that means the same thing it did last week.