AI · Agents & Intelligent Automation

An agent is a model with permission to act. The design is the permission.

Noble builds agents that do work inside an organisation’s systems — raise the ticket, reconcile the record, schedule the visit, draft and route the response — on an identity with exactly the permissions the task needs, with a stopping condition written before the first tool is connected, and with a person reviewing every action whose cost of being wrong is high. Where the rules are stable, Noble builds automation without a model at all, because a deterministic process does not need to be clever.

Which kind of automation the problem needs

Most automation that an organisation needs is not intelligent, and should not be. If the rule is "when a purchase order over the threshold arrives, route it to the plant controller", a workflow engine does that perfectly, forever, and can be audited by reading it. Noble builds that kind first, and builds it deterministically. A model is introduced only where the input is too varied for a rule — an email in free text, a document in an unknown layout, a request that has to be understood before it can be routed.

An agent is the case beyond that: a model that decides which of several tools to call, in what order, to reach a goal, and that keeps going until it gets there or hits its stopping condition. That is genuinely useful and genuinely dangerous, and the whole of Noble’s design for it is about the second half. An agent runs on an identity with the least permission that lets it succeed, it can read more than it can write, every action it takes is logged as its own, and any action past a defined cost — money, a customer, a record that cannot be undone — waits for a person.

The agent loop, with its stopping check

Plan, act through a tool, observe the result, and check — is the goal reached, is the budget spent, is the next action one a person must approve? The check is the gate, and the loop leaves through it or not at all.

What the service covers

Agents that call real systems

Agents built on the organisation’s existing APIs and applications — the ticketing system, the ERP, the document store, the calendar, the messaging platform — each exposed to the agent as a tool with a schema, a permission and a cost. The agent is given the smallest tool set that lets it complete its task, and each tool call is logged against the agent’s own identity so that its actions are distinguishable from a person’s.

Tools defined with a schema, a permission and a cost
The smallest tool set that completes the task
Agent identity distinct from any person’s
Read broadly, write narrowly

Orchestration across applications

Multi-step work that crosses systems — understand the request, look up the account, check the policy, draft the response, open the case, notify the owner — orchestrated with the state of each step recorded, so a failure in the fourth step does not lose the first three and a person can pick the work up exactly where the agent left it.

Step state recorded, so work resumes where it stopped
Orchestration across ticketing, ERP, documents and messaging
Retries, timeouts and idempotency made explicit
Handoff to a person with the full context attached

Stopping conditions and budgets

Every agent is given, before it is connected to anything, a written definition of done, a budget of steps and cost it may not exceed, and a list of actions it must stop and ask before taking. These are enforced by the runtime, not by the prompt — the model is asked to respect them and the system makes sure it does.

Definition of done written before the first tool is connected
Step and cost budgets enforced by the runtime
Actions past a defined cost wait for a person
A kill switch, and a rollback path for what an agent has done

Human review, proportionate to the risk

Not every action needs a person, and a review queue that approves everything is a rubber stamp. Noble designs the review boundary by the cost of being wrong: an internal note is committed; a customer message is shown first; a payment, a deletion or a contractual change always waits. The boundary is written down, configured, and moved only with evidence from the record of what the agent has done.

Review boundary set by the cost of being wrong
Payments, deletions and contractual changes always wait
Review queues designed for the person reviewing
Boundary moved only on evidence from the record

Process automation where the rules are stable

Deterministic workflow for the majority of automation an organisation needs: routing, approval, notification, reconciliation and scheduling built on a workflow engine, with a model introduced only at the step where the input is too varied for a rule. The result is auditable by reading it, and it does not change its behaviour when the model vendor ships an update.

Workflow engine first; a model only where a rule cannot reach
Routing, approval, reconciliation and scheduling
Behaviour stable across model updates
Auditable by reading the process

Running agents in production

An agent in production is watched like a person with system access would be: what it did, what it cost, where it stopped and asked, and where it failed. The record is reviewed on a rhythm with the process owner, and it is what justifies widening the agent’s permissions — or narrowing them.

Every action, cost and stop in one record
Reviewed on a rhythm with the process owner
Permissions widened or narrowed on evidence

Where this connects

The services alongside

Describe the task, and what going wrong would cost.

Those two facts decide the design — whether it needs a model at all, and where the person sits. Bring them, and the rest is engineering.

Contact Noble