Skip to content
Robota

AI Agents

Build an AI agent around one recurring decision.

For teams where the same kind of request arrives every week and one person ends up answering all of them.

It reads the records you approved, drafts the response, and stops when something is missing or does not match.

Symptoms

If any of this sounds like your week

At a clinic, the front desk answers the same insurance question all week, and the answer is always in the same document.

At a wholesaler, the account team retypes order details out of an email and then emails the customer back to confirm what they just typed.

At an agency, the project lead spends every morning sorting incoming requests by rules they could write down on one page.

What you get

What you have at the end

  1. 01

    A written list of the cases the agent answers, and the ones it hands straight to a person.

  2. 02

    A named reviewer, and the screen they review on.

  3. 03

    A record of every request it touched: what it read, what it proposed, who approved it.

  4. 04

    A set of test cases you can run again yourself after any change.

  5. 05

    An off switch.

Inside the system

Let the routine cases move on their own. A person still decides the rest.

Choose agent context

Approved response guidance selected. The draft now uses that source and its approval rule.

Sample interface · Support agent.

Inputs and states
Documents the required fields, which source wins when two disagree, and the states a case can be in.
Permission boundary
Lists what it may read, what it may call, and what it may never do without a person.
Decision rules
States the conditions for routing, drafting, pausing, and declining.
Review and exception path
Sends the missing, conflicting, and sensitive cases to a named reviewer with the source attached.
Action history
Records the request, the source, the rule, the proposal, and the decision.

Fit

Use an agent when the decision can be bounded.

It works when the same kind of request keeps arriving and the rule behind the answer is already written down somewhere.

This fits when

  • The same request arrives most weeks.
  • The answer already lives in a document or a record, or in someone's head, if they're willing to write it down.
  • One person is prepared to review what it proposes.

This is the wrong engagement when

  • The rule changes case by case and nobody can say why it changed.
  • The records it would read are wrong today. Fix those first, or an agent will only spread the error faster.
  • The task happens a handful of times a year. A checklist will cost you less than we will, and you should write one.

Delivery

Nothing launches until the awkward cases are written down.

We build from written cases, test every action the agent is allowed to take, and release it on a narrow slice of real work.

  1. 01

    Case map

    Covers the common case, the missing-information case, and the case where two records disagree.

    You keepThe case list, in writing.

  2. 02

    Tool boundary

    We try the actions the agent is not allowed to take, and confirm that each one fails.

    You keepThe permission list, and the test that proves it.

  3. 03

    Evaluation set

    Runs a fixed set of cases against the written rules, so a change that breaks one shows up.

    You keepThe evaluation set, yours to rerun.

  4. 04

    Staged release

    Starts on a narrow slice of real work, with the history visible and a way back.

    You keepThe rollback plan, and the first action history.

Engagement

What the engagement commits you to

Fixed scope around one process. The diagnostic comes first, and it commits you to nothing.

  1. 01

    The diagnostic covers one process, obligates no build, and what it produces is yours either way.

  2. 02

    A build is quoted after the diagnostic, against a written scope. Before that we would be guessing at your records.

  3. 03

    From your side we need the person who does the work now, and the person who owns the decision. Not a project team.

  4. 04

    If the diagnostic says an agent is the wrong answer, we say so and tell you what we would do instead.

Questions

Will it send anything to a customer without us?

No. It prepares the response and a person releases it. If you later want certain replies to go out directly, that is a change you approve, never a default.

What happens when it gets something wrong?

It stops and hands the case to your reviewer with what it read and what it proposed. They see the same record it saw.

How long does a first agent take to build?

We scope that in the diagnostic. Anyone who answers before seeing your records and your exception rate is guessing.

Do we have to replace the software we already use?

No. The agent reads and writes through the systems you already run, using the same permissions a person would have.

What if we want to stop using it?

You turn it off and the work goes back to running the way it does today. Nothing in the process depends on the agent existing.

Use cases

  • Use case

    Clinic intake triage

    New patient inquiries arrive by form, phone note and email. The agent reads each one against the intake rules and proposes the right clinician and the right slot type.

    How it works
    Nothing is booked and nothing is answered until a person releases it. Anything clinical goes straight to a clinician.
    Describe one process for Clinic intake triage
  • Use case

    Contractor quote follow-up

    Quotes go out and then go quiet. The agent tracks which ones are still open, pulls the job detail back up, and drafts the follow-up the estimator would have written.

    How it works
    The estimator sends it. Price changes, scope changes and anything a customer disputed stay off the agent entirely.
    Describe one process for Contractor quote follow-up

Bring one repeat decision. We show you where a person stays in it.