An agent should
earn its place.

A customer repeats a problem on three calls. Sales makes a promise. Success spots renewal risk. Engineering ships a fix. Each team has a piece of the story, but someone still has to connect the pieces and make sure the work reaches the customer.

We built BoB for that gap. His job is to find what deserves attention, explain why, and bring the next step close enough that a person can make a decision. The unit of value is work the team accepts. A longer conversation or a busier feed is not evidence that the team is better off.

A ticket says exports are broken. A call explains why that matters before renewal. A project shows whether somebody is already fixing it. Useful judgment depends on seeing those relationships.

BoB investigates through the tools and data available to a run. Findings carry references to the calls, signals, documents, and other records behind them. When an approved action creates a project, the evidence can travel with it. A person picking up the work should be able to see why it exists.

AOT addresses a related question: how much of the relevant evidence can you retrieve? BoB’s question is what deserves to happen next. Retrieval quality and decision quality need their own evaluation; a retrieval benchmark alone does not establish that an agent made the right decision.

A loop gives BoB a continuing responsibility. A morning brief looks for meaningful changes. A watch follows a specific risk. Call follow-through turns a conversation into proposed next steps. A specialist stays inside a narrower mandate.

Each investigation starts with a goal, a scope, and the context available to it. BoB is instructed to investigate before proposing, check for existing work, and avoid repeating a finding unless the evidence has changed. If nothing clears the bar, an empty brief is a valid result.

BoB can investigate and propose work without being allowed to carry out every change he imagines. Connected integrations require permission. Personal findings and company findings have different visibility boundaries.

A decision card makes the proposal reviewable: what happened, why it matters, the evidence, and what approval will do. Customer-facing and workspace changes go through the approval path. The proposed work then runs through the application’s services, and the card records the resulting artifact or action.

For a proposed action, approval and execution are distinct. The implementation records the applied result before recording its earning. That distinction matters: an intention to do the work is not the same as a completed deliverable.

BoB’s feedback includes accepted work, rejection reasons, dismissals, and engagement. His self-audit is instructed to compare what he produced with what the team actually found useful, then save the retrospective so it can inform later runs.

The audit can propose changes to BoB’s own behavior: cap a noisy loop, pause one that is not helping, or retire it. A lesson about how to perform a class of work can become a proposed skill update. These are reviewable changes to memory, procedures, and operating behavior—not a claim that every click retrains the underlying model.

Pay-for-outcome begins with a concrete definition of useful work. In BoB, that can be an accepted finding or an approved deliverable: a follow-up draft, a routed issue, a project with customer evidence, or another supported action. The outcome economy records accepted work and applied proposals.

A draft is a draft. A project is a project. Neither is a promise that a deal will close or a customer will renew. Making the deliverable explicit lets the team decide whether it is worth doing and inspect what was delivered.

Our design principle is simple: the agent should have a reason to do fewer, better things. It should carry the context, investigate the problem, respect the decision, and earn its place through work that matters.