[00]Keelo — the autonomous agent factory
Keelo finds the repetitive work in your business and builds the agents that do it.
It learns how your business actually works.
It builds the agents that work needs.
It runs them inside the tools your team already uses — and fixes them when they break.
Runs in your cloud. Your data stays in your environment. You own the IP.
- [03]AgentsSelf-healing
- [02]KeeloThe Brain
- [01]Your systemsERP · mail
[01]How it works
Three things, in order.
Learn the work
Keelo watches how a job actually gets done — the files people open, the systems they switch between, the exceptions they handle, the calls they make from memory. Not what the process document says. What people actually do.
You get a ranked list of the work worth automating, with the reasoning attached.
Build the agent
It designs and writes the agent that work needs — reading documents, checking invoices against orders, classifying items, flagging the risky ones, routing approvals. Then it grades itself against real past examples before anyone sees the output.
Nothing ships until it passes on work you already know the answer to.
Run it and keep it working
The agent lands in Slack, the ERP, or the queue your team already opens. Keelo watches every run, catches it when it breaks, writes the fix, and opens a pull request for a person to approve.
Your team approves the work. Keelo does the work of keeping it alive.
Most platforms hand you tools to build agents. Keelo builds them, runs them, and fixes them.
[02]Plainly
So what is it, exactly?
Keelo is software you install into your own cloud. Once it is there, it does the job an in-house AI team would do — except it does it continuously and it does not need to be hired.
It finds the work worth automating. It writes the agent. It puts that agent where the work already happens. It watches the agent run, and when something breaks it writes the fix and asks a person to approve it.
You do not build anything. You approve things.
[03]Deployment surface
Agents deploy into the systems you already run.
No new tool. No migration. No second system of record. The agent lands in the application where the work already happens, and the approval lands where the person already is.
- Oracle NetSuite
- AWS
- Azure
- ServiceNow
Every deployment runs inside infrastructure you control. These are systems Keelo agents read from and write to — not customer logos.
System names are trademarks of their respective owners and are shown to describe integration compatibility, not partnership or endorsement.
[04]The problem
95%
of enterprise generative-AI pilots return nothing measurable to the P&L.
Against $30–40 billion of enterprise investment, almost none of it reaches the income statement. The pilots are not failing because the models are bad. They are failing at everything that happens after the demo.
The projects that do return something look structurally different from the ones that do not. They are embedded in a workflow people already run rather than presented as a new tool. They retain feedback instead of discarding it. They adapt as the data underneath them changes, and they get better with use rather than degrading quietly.
That description is a specification. It is the difference between a pilot and an operating system, and it is what this platform is built to produce by default.
Source
The GenAI Divide: State of AI in Business 2025
MIT Project NANDA
300+ public initiatives reviewed, 52 structured interviews, 153 leader surveys.
[05]What ships
The model is not the strategy. The deployment is.
Anyone can get a model to do something impressive in an afternoon. Keeping it working for two years is the hard part. Here is everything that arrives so it does.
- The agent, running in your cloud
- Deployed into your accounts and your environment, wired to the systems it needs to read and write. Not a tenant on someone else's platform, and not a workflow you rent back.
- The harness around it
- Permissions, tool access, retries, timeouts, rate limits, fallbacks, and escalation paths. This is the part that decides whether the agent still works in six months, and it is inherited rather than improvised.
- The eval suite that gates it
- Golden sets, holdout sets, per-field scoring, and the pass threshold an output has to clear before release. Written alongside the agent, not after the first failure.
- The approval surface
- In Slack, the ERP, or the queue your team already opens. Every output arrives with per-field confidence and a citation to where it came from, so the approver reviews evidence instead of trusting a number.
- Observability from run one
- Per-run structured logs — inputs, model calls, tool calls, outputs, confidence, and who approved what. Nothing is reconstructed after the fact, and this is what lets the fleet repair itself.
- The source, and the IP
- You own the agent and the workflow logic encoded in it. Permissive open-source licenses only, audited before anything reaches your environment.
First agent in production in weeks. Every one after it lands faster, because the factory keeps what it learned building the last.
[06]The Keelo Loop
Six modules the factory runs on its own — and the five places it stops for a person.
Autonomous does not mean unsupervised. Each step runs on its own and then stops at a point where a person decides. The last step feeds the first, which is why the whole thing speeds up the longer it runs.
[01]Design
Discovery that watches the work
A discovery agent observes real day-to-day work in situ, extracts the schema of each repeated workflow, and scores every candidate on automatability and P&L impact.
- Runs on its own
- Runs continuously against real work rather than waiting to be pointed at something. It finds new candidate workflows as volumes shift and exceptions recur, and re-scores the queue on its own.
- Where a person decides
- You approve what enters the build queue.
[02]Plan
Frontier reasoning decides the architecture
A frontier reasoning model architects the agent: what must be deterministic versus reasoned, the harness specification, guardrails, and exactly where a human signs off.
- Runs on its own
- Architects the whole agent — the deterministic/reasoned split, the harness spec, the guardrails, the data contracts, and exactly where a person signs off.
- Where a person decides
- An engineer reviews the blueprint before any code is generated.
[03]Build
The model writes the agent
The model generates the code, harness, deterministic rules, and security controls on top of ingestion pipelines, normalization, schema mapping, and eval gates that already exist.
- Runs on its own
- Generates the agent against the blueprint, assembles it from the Brain's reusable layers, writes the eval set alongside it, and grades itself. It will not ship what it cannot pass.
- Where a person decides
- Release is gated on the eval threshold and an engineer's merge.
[04]Deploy
Meet the human where they are
The agent lands in the exact system and approval surface the team already lives in. A file drops in Slack, the agent runs the pipeline, a person approves the result.
- Runs on its own
- Provisions into your environment, wires the integrations, and stands up the approval surface inside the system the team already opens.
- Where a person decides
- You approve the rollout — and every write to a system of record after it.
[05]Manage
The fleet largely maintains itself
Every agent streams logs to a monitoring pipeline. The self-healing loop detects the bug, files the issue, triages it, writes the fix, and opens a pull request.
- Runs on its own
- Watches every run. Detects the regression, files the issue, triages it against the failure history, writes the fix, and opens the pull request.
- Where a person decides
- A person reviews and merges. This step stays human on purpose.
[06]Learn
Two loops, one compounding effect
The inner loop improves each agent from its own outputs and human corrections. The outer loop improves the platform, so the next Design and Build start further along.
- Runs on its own
- Feeds every correction back into the agent and every reusable component back into the Brain, so the next build starts further along than the last.
- Where a person decides
- None required. This is the part that compounds on its own.
[07]The Keelo Brain
Your agents get better because the context does.
The Brain is the control plane, and it is where context accumulates. Context flows into it — from the work discovery observes, from every correction a person makes at an approval surface, from every run the fleet completes — and it flows back out into the agents. It holds three registers: the reusable machinery every agent is assembled from, everything Keelo has learned about how your business actually runs, and the live state of every agent running for you. The middle register is the one that compounds — which vendor sends files that break parsers, what your team calls things, which exceptions get handled by hand and why. None of it is written down anywhere else, and it is why the tenth agent understands your business better than the first did.
[03]Shipped and self-healing
Agents
Each one leaves with the harness, the guardrails and the eval gates already attached.
[02]The Brain · context layer
Keelo
The control plane. It ingests your context, holds what has been learned about how your business runs, and every agent is assembled from it.
[01]ERP · mail · file stores
Your systems
Context flows up out of them, and the corrections your team makes flow back down.
- [01]Reusable layers
- Ingestion and vision, normalization, the agent harness, guardrails, eval gates, observability, and model routing. None of it is written per deployment. It already exists, it has already met real enterprise documents, and it is the difference between a generated agent and a production system.
- [02]Context
- Vendor quirks, house naming, the exceptions your team handles by hand, and the reasoning behind every past decision — recorded with the evidence that justified it. Every entry is a versioned file, so the commit history is a decision trace you can actually read.
- [03]Fleet state
- Per-run telemetry from every agent in production, aggregated into accuracy, cost, and latency trends, plus eval history per agent and per output class. This is the register the self-healing loop reads from — which is why observability is a precondition here and not a report.
Decision tracing
Every decision keeps its reasoning.
When an agent classifies a line, flags a discrepancy, or routes something for approval, the decision is stored with what it was based on — the source it read, the rule it applied, the confidence tier it landed in, and who approved it. A year later you can ask why a call was made and get the actual answer rather than a guess.
- Traceable
- Every output resolves back to the exact run, input, model calls and reasoning that produced it.
- Cumulative
- Corrections are not discarded after the fix. They become the context the next agent starts from.
- Yours
- The context is about your business, it stays in your environment, and it leaves with you.
The data boundary
Every Brain runs inside one deployment. What crosses between deployments is how to build agents — never what Keelo learned about your business.
- Your raw data never leaves your deployment
- Not documents, not records, not run rows. What Keelo holds centrally receives aggregates only — accuracy, cost, latency — never source data. The rule is enforced in the repository itself rather than left to anyone's judgment on the day.
- Your workflow logic stays yours
- The business rules, taxonomy, and exception handling encoded into your agent are scoped to your deployment and owned by you. They are not blended into anything shared, and they do not inform anyone else's build.
- What crosses deployments is engineering knowledge
- How a parser survives a merged cell. Which eval catches which class of failure. Which guardrail shape fits an approval surface. That is Keelo's own learning about how to build agents, and it is the reason the second agent costs less than the first.
[08]Self-healing
It finds its own bugs. It still cannot deploy its own fixes.
Every agent emits per-run structured telemetry on exit. A separate watchdog process reads it — never the agent's own code judging itself — and turns a failure into a filed, deduplicated, evidence-carrying issue before anyone notices the output was wrong.
[01]Detect
Telemetry crosses a threshold, an eval starts failing, or an output pattern shifts.
[02]File
The loop opens an issue with the failing runs, the diff in behavior, and the suspected cause.
[03]Triage
The failure is classified against the agent's history and the known failure library.
[04]Fix
The loop writes the change and opens a pull request with the eval results attached.
[05]Merge
A person reviews and merges. This step stays human on purpose.
[06]Healthy
The agent returns to baseline, and the fix becomes prior art for every other agent.
The eleven classes it catches
- dangling_run
- Died or hung. No end event was ever written.
- fatal_error
- The run terminated on an unhandled exception.
- fatal_transient
- Killed by something the retry policy should have absorbed.
- api_burn
- Structurally identical API errors in a loop — money burning silently.
- error_streak
- Repeated errors across consecutive runs.
- stage_error
- A stage failed and the pipeline continued anyway.
- empty_output
- Reported success with nothing to show for it.
- partial_status
- Self-reported degraded completion.
- schema_violation
- The instrumentation itself broke.
- latency_ceiling
- Per-run latency budget exceeded.
- cost_ceiling
- Per-run cost budget exceeded.
Could a machine-written change reach your production system on its own?
A watchdog that only files issues still leaves the work to a person. The fix loop closes it — and the architecture is built so the honest answer to “could this change my production system on its own?” is no, enforced by code paths rather than promised by policy.
[01]
It never touches the running agent
The fixer clones the agent's repository at its deployed tag into a scratch directory. It does not read from, write to, or rebuild the running container. The live agent is untouched for the entire attempt.
[02]
Everything executes in a throwaway sandbox
The reproduction, the full test suite, and a differential replay against recorded runs all execute in disposable containers with networking disabled. Nothing the fixer runs can reach your systems, because nothing it runs can reach the network.
[03]
The output ceiling is a draft pull request
There is no merge path anywhere in the fix code. The most an autonomous attempt can produce is a draft PR on the development repository, with the failing reproduction, the diff, and the eval results attached. A draft PR is a proposal, not a deployment.
[04]
Three separate people, three separate steps
A person labels the finding as approved for a fix attempt — without it the attempt never starts. A person reviews and merges the pull request. A person cuts the release that actually deploys. No single approval can carry a machine-written change into production.
[09]Why now
Three curves crossed. The constraint moved.
The constraint on enterprise automation is no longer model capability. It is having a system that converts capability into operating leverage, repeatably, without adding headcount for every new workflow.
01
Agents crossed from demo to dependable
For structured, judgment-light enterprise work, model reliability is now good enough to trust in production — with the right harness around it. The harness is the condition. Without evals, guardrails, deterministic fallbacks, and an approval surface, the same model that passes a demo fails a Tuesday.
02
The economics finally work
Value-tier model costs fell roughly 80% year over year. Work that was uneconomic to automate in 2024 is routine to automate in 2026. The threshold for “worth building an agent for” has dropped by an order of magnitude, and it keeps dropping.
03
The knowledge is still in people, not systems
Workflow logic, vendor quirks, exception handling, and house taxonomy live in a handful of heads. None of it is written down. The window to encode that knowledge into a system is open right now, and it closes one retirement and one resignation at a time.
[10]The platform, measured
Numbers from Keelo's own machine.
These are operating measurements of the platform, not projections and not customer outcomes.
Measured
- 99.9%
- Uptime across the deployed agent fleet, trailing 90 days
- A run that could not start or complete on a healthy input counts against it.
- Under $2
- Median cost per production agent run
- Model and infrastructure. Engineering time is not in the number.
- Under 5s
- Median latency on validation-class runs
- Wall clock, trigger to result, including every model call in the pipeline.
True by construction
- 0
- Writes to a system of record without a human approval
- 96%
- Holdout pass rate below which release is blocked
- 6
- Reusable platform layers every new agent inherits on day one
The three measured figures come from Keelo's own run telemetry across agents running in customer environments, on the window stated in each label. They describe the platform's operation, never a customer's results. The invariants below them are not measurements — they hold by construction, which is why they carry no window.
[11]Compounding
Every agent the factory ships makes the next one cheaper to build.
Nothing gets built twice. Whatever the last agent needed — a way to read a file format, a rule, a test — the next one inherits. So the tenth agent is far cheaper than the first.
01
Ship
A workflow comes off the scored build queue and becomes a production agent, running in your environment, in weeks.
02
Correct
People approve and reject its outputs. Every rejection is labeled signal. The agent improves against its own production record, not a benchmark.
03
Generalize
The pipeline, the schema mapping, the guardrail, and the eval set stop being specific to one workflow and are written back to the Brain.
04
Compound
The next Design opens with more prior art, the next Build opens with more finished machinery, and the next agent costs less than the one before it.
[12]The difference
Most enterprise AI work stops at the demo. The factory starts there.
| Dimension | The conventional approach | Keelo |
|---|---|---|
| Where it starts | A workshop, an org chart, and a list of ideas from leadership. | A discovery agent observing the actual work, ranked by frequency and P&L impact. |
| What ships | A pilot in a notebook or a chat window. | A production agent with a harness, guardrails, evals, logs, and an audit trail. |
| Where it lives | A new tool your team has to be trained on and remember to open. | Inside Slack, the ERP, or the ticket queue the team already uses. |
| When it breaks | You file a ticket. Someone scopes a change order. | The loop detects it, files it, writes the fix, and opens a PR. A person merges. |
| When the model changes | A rebuild, re-scoped and re-billed. | The routing layer swaps the model. Evals confirm the swap. The agent keeps running. |
| What the second agent costs | The same as the first. Every project starts at zero. | Less than the first. Pipelines, schemas, guardrails, and evals carry forward. |
| Who owns it | The vendor owns the platform. You rent access to your own workflow. | You own the code, the IP, and the cloud it runs in. Permissive licenses only. |
| What it costs to scale | Headcount grows with every customer and every agent. | The fleet largely maintains itself. Headcount does not track agent count. |
[13]Where it runs
Document-shaped work, at volume, where being wrong is expensive.
Six workflow archetypes the factory is built for. Underneath the industry labels, almost every one of them is the same job: something arrives, someone reads it, someone checks it against a system. All six are currently held together by a small number of people.
[01]
Document intake and coding
Supplier and counterparty documents become structured records your systems can act on.
[02]
Specification and order conformance
Every spec checked line by line against the standard before money is committed.
[03]
Landed cost and rate refresh
Current routed rates replace the historical average every margin model quietly depends on.
[04]
Tariff and regulatory classification
The correct code assigned to every item at catalog scale, before production locks.
[05]
Allocation & replenishment validation
High-volume submissions validated against constraints before they reach execution.
[06]
Transaction risk triage
Deterministic rules first, reasoning on the residual, humans only on the genuinely ambiguous.
Where those shapes show up
[14]Control
Agents propose. People approve.
No agent writes to a real system without someone saying yes. Every control below is on from the first day, not added after something goes wrong.
- Deployed in your environment
- Agents run in your cloud and your accounts. There is no multi-tenant platform your workflow data has to pass through.
- Data stays where it is
- Your data is not used to train models, is not pooled across customers, and does not leave the environment it already lives in.
- You own the IP
- You own the agent, the code, and the workflow logic encoded in it. Keelo retains its reusable platform layers. That boundary is written into the contract, not left to interpretation.
- License-clean by discipline
- Permissive open-source only, such as Apache-2.0. Dependency licenses are audited, and copyleft exposure is remediated before deployment. No agent ships with an unresolved license question.
- Human approval on every write
- No agent output reaches a system of record without a person approving it. Escalation paths are defined at design time. It fails safe, never silent.
- Full audit trail
- Every run is logged end to end — inputs, model calls, tool calls, outputs, confidence, and who approved what. Every decision is reconstructable after the fact.
[15]Get started
Bring the workflow that matters too much to leave as a prompt experiment.
The first conversation is about which workflow is worth encoding, what has to stay human, what has to be governed, and what system needs to exist around the model. It is a technical conversation with the person who will build the thing.
Keelo takes on a small number of deployments. The work has to matter — to the business, to the people doing it, and to Keelo.
Direct: Edward@keelo.ai