Skip to content

The platform

Deploy it once. It runs the agent lifecycle without being asked.

There are two parts. The Brain is everything Keelo already knows — the code it reuses, the lessons from every agent built before, and the live state of every agent running now. The Loop is the six steps that run on top of it: find the work, design the agent, build it, ship it, watch it, and fix it.

Talk to an engineer

[01]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.

  1. [03]Agents

    The agent fleet

    Self-healing

  2. [02]Context

    The Keelo Brain

    Learned over time

  3. [01]Connectors

    Your systems

    ERP · Slack · mail

[01]

Reusable layers

Inherited on day one · the register that crosses deployments

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.

  • Ingestion and vision pipelines
  • Unstructured-to-structured normalization
  • Agent harness and guardrails
  • Eval and QA gates
  • Observability and self-healing
  • Model routing

[02]

Context

What Keelo has learned about your business · never leaves it

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.

  • How your systems behave
  • Exceptions and how they get handled
  • Decisions, with the evidence
  • Postmortems: symptom, cause, fix

[03]

Fleet state

What your agents are doing right now · never leaves your cloud

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.

  • Per-run telemetry
  • Eval history
  • Cost and accuracy trends
  • Failure classification

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.

[02]Register 01, in detail

The moat is not the model. It is everything around it.

Models are a commodity anyone can rent. What compounds is the reusable machinery an agent is assembled from. Every layer below was built once, for a real production system, against real enterprise data.

  1. [01]Read

    Ingestion and vision pipelines

    Object detection, OCR, and PDF parsing that hold up against documents produced by people who were not thinking about your parser. Handles the scanned page, the merged cell, the photograph of a spec sheet.

  2. [02]Shape

    Unstructured to structured normalization

    The layer that turns what arrived into what the system needs. Unit reconciliation, format collapsing, entity resolution, and confidence scoring on every field it emits.

  3. [03]Run

    Reusable agent harness and guardrails

    Permissions, tool access, retries, timeouts, rate limits, fallbacks, escalation paths, and audit trails. The agent inherits all of it. Nobody rebuilds it per deployment.

  4. [04]Grade

    Eval and QA gate library

    Every output is graded before it ships. Golden sets, holdout sets, per-field scoring, and a pass threshold that blocks release. Evals are not optional and they are not written after the fact.

  5. [05]Watch

    Observability and self-healing infrastructure

    Structured, per-run logging on every agent, streaming into the pipeline that feeds the repair loop. Observability is not reporting. It is the precondition for a fleet that fixes itself.

  6. [06]Route

    Model routing

    Frontier models for judgment. Value-tier and open models for volume. Routing is per task, not per vendor, which means a model deprecation is a configuration change and not a rebuild.

A Keelo agent starts at a higher baseline than one built from scratch, and your second agent costs less than your first. Not because the model got better. Because the Brain did.

[03]The Keelo Loop

Six modules. Each runs on its own, hands an artifact to the next, and reads and writes the Brain as it goes.

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.

Takes in
Real observed work
Hands over
Workflow schema and a scored build queue

[01]Design

Discovery that watches the work, not the org chart.

Most automation programs fail before a line of code is written, because the workflow list came from a meeting instead of from the work.

A discovery agent runs on an employee's machine and observes real day-to-day work in situ. It sees which files get opened, which systems get switched between, which steps repeat, which exceptions recur, and how long each pass takes. It does not ask people to describe their process, because people describe the process they are supposed to follow rather than the one they run.

From that observation, the agent extracts the schema of each repeated workflow and its frequency. It scores every candidate on two axes: how automatable the work is, and what it is worth to the P&L. The output is a ranked build queue, not a report.

In
Real observed work
Out
Workflow schema and a scored build queue
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.
Draws from the Brain
Workflow patterns already seen in comparable operations, and the scoring model refined against every prior discovery.
Writes back
New workflow schemas, and what the scoring got right and wrong.

Task schema extraction

Every repeated workflow is reduced to its inputs, transformations, decision points, exceptions, and outputs. That schema is what the next module architects against.

Automatability and impact scoring

Each candidate is ranked on how cleanly it can be encoded and what it costs the business today. Judgment-heavy work is deliberately scored down, not up.

Scoped, auditable observation

Discovery runs on infrastructure you control, against a defined scope agreed in advance, with a complete record of what was observed and what was not.

Observing how enterprise work actually happens is a signal nobody else collects. It is the wedge and it is the data that compounds.

[02]Plan

A frontier model architects the agent before anything is built.

The gap between seeing the work and writing the agent is where most production failures are decided.

A frontier reasoning model takes the workflow schema and produces the agent's architecture. It decides what must be deterministic and what should be reasoned. It specifies the harness, the security controls, the data contracts, and the guardrails. It defines where a human signs off, and on what.

This is the one place in the loop where a premium model earns its price. Architecture is a judgment problem, and judgment is where frontier reasoning is worth paying for. Everything downstream runs on cheaper, routed models, because everything downstream is executing a decision that has already been made well.

In
Workflow schema
Out
Agent blueprint: harness spec, deterministic/reasoned split, HITL surface, guardrails
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.
Draws from the Brain
Architecture patterns, and the decisions — with the evidence behind them — from every harness choice already made.
Writes back
A new blueprint, and the reasoning that produced it.

Deterministic before reasoning

If a rule can express it, a rule expresses it. Models are used where the input genuinely varies, not where a regular expression would have worked. This is a cost decision and a reliability decision at the same time.

Harness specification

Tool access, permissions, retries, timeouts, escalation paths, and failure modes are specified before implementation rather than discovered in production.

The human-in-the-loop surface

The blueprint names exactly which decisions a person makes, what they see when they make it, and what happens when they reject. Approval is designed, not bolted on.

Guardrails and data contracts

What the agent may read, what it may write, what shape the data must be in at each boundary, and what happens when a contract is violated.

[03]Build

The model writes the agent. The plumbing is why it survives production.

Generating agent code is the easy half. The half that decides whether it still works in six months is underneath it.

The model generates the agent code, the harness, the deterministic rules, the security controls, and the reasoning components against the blueprint. That part is fast, and it is getting faster.

What makes the result a production system rather than a prototype is the layer it is assembled from: ingestion and vision pipelines, unstructured-to-structured normalization, schema mapping, and eval gates that grade every output before it ships. None of that is generated fresh per agent. It already exists, it has already met real enterprise documents, and it is reused.

In
Agent blueprint
Out
A deployable agent that has passed its eval gate
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.
Draws from the Brain
The reusable layers in full: ingestion, normalization, harness, guardrails, and the eval gates that grade the output.
Writes back
Any component general enough for the next agent to inherit, plus the eval sets written alongside it.
Why eight stages at 95% return 66%

Generated against a specification

The model implements a blueprint rather than improvising an architecture. Generated code that satisfies a spec is reviewable. Generated code that satisfies a prompt is not.

Assembled from the Brain's reusable layers

Ingestion, vision, normalization, schema mapping, and guardrails are inherited from the Brain, not written. The engineering that took the longest to get right is the engineering nobody rebuilds.

Eval gates before release

Every output class is graded against golden and holdout sets. An agent that does not clear its threshold does not ship. Evals are written with the agent, not after the first failure.

License-clean by discipline

Permissive open-source only, such as Apache-2.0. Dependency licenses are audited, and copyleft exposure is identified and remediated before anything is deployed into your environment.

Anyone can call an LLM. What makes these agents run in production rather than in a notebook is the engineering underneath — and none of it is rebuilt per agent.

[04]Deploy

Deployed where the work already happens.

An agent that requires people to open a new tool is an agent that gets used for three weeks.

The agent lands in the exact system and approval surface the team already lives in. If the work happens in Slack, the agent lives in Slack. If it happens in the ERP, the agent writes into the ERP. There is no new interface to learn, no new login, and no second system of record.

The standard pattern is simple and it is the one people actually adopt: a file is dropped in the channel the team already uses, the agent runs the pipeline, the result comes back in thread with its confidence and its sources, and a person approves it.

In
Deployable agent
Out
A live agent inside your system, with an approval surface
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.
Draws from the Brain
Deployment and approval-surface patterns already proven in other environments.
Writes back
Which surfaces held under real use and which needed rework, per system.

Meet the human where they are

The approval surface is chosen to match existing behavior. Adoption is a design constraint, not a change-management problem to solve afterward.

Agents propose, people approve

Nothing reaches a system of record without a person signing off. Where the agent is uncertain, it escalates rather than guessing. It fails safe, never silent.

Runs in your environment

Deployment targets your cloud and your accounts. Data stays inside the environment it already lives in.

Confidence and provenance on every output

Each result arrives with per-field confidence and a citation to where it came from, so the approver is reviewing evidence rather than trusting a number.

[05]Manage

The fleet detects its own failures and opens its own pull requests.

This is the module that breaks services economics.

Every agent streams structured, per-run logs into a monitoring pipeline. That pipeline is not a dashboard. It is the input to the repair loop.

When an agent starts failing — a vendor changes a template, a schema drifts, an upstream API changes shape — the loop detects the anomaly, files the issue, triages it against the agent's history, writes the fix, and opens a pull request. A person reviews and merges. The agent returns to healthy, and the fix is written back to the Brain as prior art for every agent that breaks the same way.

In
Live agent telemetry
Out
Detected failures, filed issues, merged fixes, a healthy fleet
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.
Draws from the Brain
The failure library, and the fix history for every agent that broke the same way before.
Writes back
Every detection, triage, and merged fix, recorded as symptom, root cause, fix, prevention.

  1. [01]Detect

    Telemetry crosses a threshold, an eval starts failing, or an output pattern shifts.

  2. [02]File

    The loop opens an issue with the failing runs, the diff in behavior, and the suspected cause.

  3. [03]Triage

    The failure is classified against the agent's history and the known failure library.

  4. [04]Fix

    The loop writes the change and opens a pull request with the eval results attached.

  5. [05]Merge

    A person reviews and merges. This step stays human on purpose.

  6. [06]Healthy

    The agent returns to baseline, and the fix becomes prior art for every other agent.

The watchdog

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.

  1. [01]

    Watch

    A filesystem event picks up each run manifest within seconds of the run closing. A slower sweep runs behind it as a backstop, because the failure mode that matters most is the run that never emitted an end event at all.

  2. [02]

    Tier 1 — deterministic

    Rule-based classification against the failure taxonomy. No model, no token cost, no dependency on an external service being up. This tier alone catches the majority of what goes wrong.

  3. [03]

    Tier 2 — semantic

    A model pass over findings plus a small sample of clean runs, to catch what rules cannot describe. It runs under a hard daily spend cap and always fails open to Tier 1 — a budget-exhausted or unavailable Tier 2 degrades the watchdog, it never blinds it.

  4. [04]

    Fingerprint and file

    Findings are deduplicated on a hash of the failure signature rather than the run, so one recurring defect is one issue with an occurrence counter instead of a thousand notifications. The issue carries redacted evidence and the run identifiers needed to reproduce it.

The failure taxonomy

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.

  1. [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.

  2. [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.

  3. [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.

  4. [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.

Observability is the precondition

Self-healing is not possible without per-run structured logging on every agent from day one. Observability is not a reporting feature bolted on later. It is the substrate the entire loop runs on.

A fleet that largely maintains itself is a fleet whose operating cost does not track its size.

[06]Learn

Every correction makes the whole platform smarter.

Two loops run at once. One improves the agent. The other improves the factory.

The inner loop is per-agent. Each agent improves from its own outputs and from the corrections humans make to them. Every rejection at the approval surface is labeled signal about a real edge case in a real business, which is a far better training input than any benchmark.

The outer loop is per-platform. The pipelines, schemas, guardrails, and eval sets learned building one agent make the next Design and the next Build faster and cheaper. That knowledge feeds back into Design, which means the next discovery starts with a better prior about what this class of workflow looks like.

In
Corrections and run history
Out
Improved agents, and reusable prior art fed back into Design
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.
Draws from the Brain
Fleet-wide accuracy, cost, and latency trends.
Writes back
Generalized components, updated patterns, and the prior art the next Design opens with.

How feedback becomes ground truth

Deterministic checks produce proofs. A model judge produces opinions. Neither knows whether the person who asked was actually served — so human reaction is captured as a third and highest tier, and it supervises the other two.

  1. [01]

    Approval is the signal, and it costs nothing to give

    A reviewer approving or rejecting an output in the surface they already use is the whole capture mechanism. Every result the agent posts is indexed, so a reaction hours or days later still resolves to the exact run, its inputs, and the reasoning trace that produced it.

  2. [02]

    A rejection is the highest-signal event in the system

    It is treated as fact rather than opinion: it emits a deterministic finding, jumps the diagnosis queue with the context that a human marked this unsatisfactory, and opens an escalation path. A rejection that visibly produces nothing teaches people to stop rejecting.

  3. [03]

    Approvals calibrate the judge

    An approval on an output the model judge had flagged records a disagreement. That becomes a continuously computed false-positive rate for the judge itself — the alternative is hand-tuning the quality bar after every review round.

  4. [04]

    Feedback becomes the corpus

    Approved outputs are human-confirmed pairs and seed the eval set. Rejected ones plus their diagnoses become the failure corpus. The eval suite an agent ships with is not the eval suite it has a year later.

Corrections flow into versioned prompts and closed vocabularies, never into model weights. Every change is eval-gated and runs in shadow mode before it is promoted, so improvement is reviewable, attributable, and revertible with a git revert.

Inner loop — the agent improves

Approvals and rejections become the agent's ground truth. Prompts are versioned, evals are regenerated against real production cases, and improvements ship through the same gate as any other change.

Outer loop — the platform improves

Every reusable component built for one agent is written back to the Brain. The next agent inherits it. The cost curve bends down with volume rather than staying flat.

Every agent the line ships lowers the unit cost of the next one. That is the whole reason this is a product and not a project.

[04]Reliability engineering

A pipeline is only as good as the product of its stages.

Reliability multiplies. An eight-stage pipeline where every stage is 95% accurate returns 66% — and every stage feels fine in isolation. To clear 95% end to end, each stage has to hold 99.4%. This is why an agent that demos well degrades in production, and it is the arithmetic that dictates almost every engineering decision below.

The arithmetic
∏ P(stageᵢ)
8 stages at 95% each
66%
Required per stage for 95% end to end
99.4%

The six rules that follow from it

The model disambiguates. It does not search.

Deterministic passes run first and narrow the space — tiered matching, closed vocabularies, regex extraction, schema constraints. The model is handed the residual it can actually reason about. Across the hardest agents built so far, the two biggest engineering sinks both converged the same way: from asking a frontier model to diagnose, to deterministic matching that escalates only genuine conflicts.

A separate oracle verifies. The model never grades itself.

Every extracted value is re-checked against the source text layer rather than asking the model whether it is confident. An agent asked to review its own work praises it. Verification is a separate deterministic path or a separate model, and it emits a hard pass or fail.

Confidence is a derivation story, not a score.

A number between zero and one tells a reviewer nothing actionable. Confidence is a deterministic ladder — text-confirmed, vocabulary-matched, cross-model agreed, misread-corrected, model-only, contradicted — and every tier carries a plain-English reason and a prescribed action. The reviewer sees why, not how sure.

Silent failure is a design defect, not an edge case.

The most expensive class of bug is output that is quietly incomplete and looks finished. Every internal state that matters is wired to a surface a person actually sees, and a blank field with a note beats a confident guess every time.

Reproducibility is part of the product.

Temperature is zero on every call in a validation path. Two runs over the same input return the same answer, or a reviewer stops trusting the output — and an agent nobody trusts is an agent nobody uses.

The ship gate is a holdout nobody has looked at.

Golden sets guide development; a separate holdout decides release, and it is never inspected while iterating. Building the eval corpus is consistently the longest pole in the work — longer than the scorer, longer than the prompt.

The confidence ladder

  1. 01 Text-confirmedValue re-read and matched in the source text layer.
  2. 02 Vocabulary-matchedResolved against a closed, curated vocabulary.
  3. 03 Cross-model agreedTwo independent passes returned the same value.
  4. 04 Misread-correctedA known deterministic correction was applied.
  5. 05 Model-onlyReasoned, with nothing independent to confirm it.
  6. 06 ContradictedSources disagree. Escalated, never guessed.

[05]Model routing

Frontier models for judgment. Value and open models for volume.

Routing happens per task, not per vendor. Keelo is model-agnostic by architecture, not by press release.

A single model for every step is a cost problem and a reliability problem at the same time. Architecture, ambiguous exception handling, and anything requiring real judgment go to a frontier model, where the premium is worth paying. Extraction, classification, normalization, and high-volume grading go to value-tier or open models, where the cost per run is what makes the workflow economic to automate at all.

Because routing is a configuration layer rather than a hardcoded dependency, a model deprecation or a better price on a new release is a config change validated by evals, not a rebuild.

Frontier
Agent architecture, ambiguous exceptions, and decisions where being wrong is expensive.
Value
High-volume extraction, classification, normalization, and routine grading.
Open / self-hosted
Work that must stay inside your boundary, or where volume makes per-token cost the binding constraint.

The model layer is the part of this stack that will be cheapest and most replaceable in two years. Keelo is architected on that assumption.

[06]Trust, security & IP

Your cloud. Your data. Your IP.

The controls below are conditions of deployment, not options on a pricing page.

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.

[07]How it is built

Seven rules every Keelo agent is built to.

  1. [01]

    Agents propose, people approve.

    Nothing reaches a system of record without a person signing off. This is the control that makes every other claim on this site defensible.

  2. [02]

    You own the IP and the cloud.

    Agents deploy into your environment. Data stays where it already lives. You own the code and the workflow logic encoded in it. Permissive open-source licenses only.

  3. [03]

    Reusability is the scoring function.

    Every component is evaluated on whether the next agent can inherit it. Work that cannot be reused needs a specific reason to exist.

  4. [04]

    Deterministic before reasoning.

    If a rule can express it, a rule expresses it. Models are used where the input genuinely varies. This is a reliability decision and a cost decision at the same time.

  5. [05]

    Evals are not optional.

    Every output class is graded against golden and holdout sets before release. An agent that has not been measured has not been built.

  6. [06]

    Observability first.

    Every agent streams structured, per-run logs from day one. An agent that cannot be observed cannot be operated, and cannot be repaired by the loop.

  7. [07]

    Fail safe, never silent.

    When an agent is uncertain, it escalates. It does not guess, and it does not quietly degrade.

Get started

The loop is running. Bring it a workflow.

The fastest way to evaluate this is to point discovery at one real workflow and see what comes back in the build queue. That conversation is technical and it happens with the person who will build the system.

Talk to an engineerStart a discovery

Direct: Edward@keelo.ai