[ AI & Automation  /  AI Agent Development ]

Agents that do work, inside limits you set.

An agent is a model that can call your tools and change real things. That makes it genuinely useful and genuinely risky, so the interesting engineering is in the permissions, the approval gates and the spend ceiling — not the prompt.

Scoped permissions · Approval gates · Full audit trail

Scopedpermissions per tool
Approvalgates on risky actions
Auditedevery action logged
Cappedspend per run

[ The risks ]

What goes wrong with agents.

Every one of these is an engineering problem with a known solution. The failure is skipping them because the demo worked.

Too much permission

An agent given broad write access because scoping it properly was more work than the prototype needed.

Loops that never end

An agent retrying the same failing step indefinitely, burning tokens until someone notices the bill.

Silent wrong actions

Something changed in a live system with no record of what it did or why.

Prompt injection through data

Instructions hidden in a document or web page that the agent then follows as if you had written them.

Unpredictable cost

Spend per run varying wildly because there is no ceiling and no step limit.

No way to test it

Behavior that cannot be reproduced, so nobody can tell whether a change made things better.

[ How it works ]

Constrain, evaluate, deploy.

01  —  Week 1

Define limits

Which tools, which permissions, which actions need human approval, and what the agent must never do. Written down and agreed before any building.

02  —  Week 2-4

Build

Tools defined with strict schemas, step and spend limits enforced in code rather than requested in a prompt, and every action logged.

03  —  Launch

Evaluate & roll out

Scored against scenarios including deliberately adversarial ones, then released to a small group first with approval gates on everything consequential.

[ What actually changes ]

The guardrails.

Constraints belong in code, not in the prompt. A prompt is a request; a permission boundary is enforcement.

Capability

  • Tool definitions — strict schemas so the agent cannot call your systems with malformed input.
  • Read and write separation — read-only by default, with writes as a deliberate, narrow grant.
  • Multi-step planning — only where the task genuinely needs it, since fewer steps means fewer failure modes.
  • Integration with your systems — through your existing APIs and permission model, not around it.
  • Human handoff — a clean escalation path when the agent is out of its depth.

Control

  • Permission scoping — the agent's access limited to the specific records the task requires.
  • Approval gates — anything expensive or irreversible waits for a human to confirm.
  • Step and spend limits — hard ceilings enforced in code, so a loop cannot run up a bill.
  • Full audit trail — every action, input and decision recorded and reviewable afterwards.
  • Adversarial evaluation — tested against injection attempts and edge cases before it goes near production.

[ Example engagement ]

Triage agent with a hard approval boundary.

An agent that reads incoming requests, gathers context from internal systems and drafts a response. It can read anything in scope and write nothing without a human clicking approve.

Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.

100%of writes human-approved
Everyaction logged and reviewable
Cappedspend per run
0unapproved changes

[ Free · honest answer ]

Does this need an agent?

Plenty of tasks called agentic are better served by a fixed workflow with one model step. It is cheaper, more predictable and easier to test. I will say so if that is your case.

Ask me

[ Pricing ]

Pricing that fits your budget.

Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.

Fixed project price

Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.

Monthly retainer

For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.

Hourly for small jobs

For a single bug or a short task where writing a full scope would cost more than simply doing the work.

Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.

[ Questions ]

Common questions.

Do we actually need an agent?

Often not. If the steps are known in advance, a deterministic workflow with a model step is cheaper, more predictable and far easier to test. Agents earn their cost when the path genuinely varies per request.

How do we stop it doing something damaging?

Permissions scoped narrowly, approval gates on anything irreversible, and hard step and spend limits enforced in code. Constraints written only into a prompt are suggestions, not controls.

Can it work with our internal systems?

Yes, through your existing APIs and permission model. The agent gets its own identity with its own limited access, so its actions are attributable and revocable.

What does it cost to run?

Modeled per task before you commit, and bounded by per-run ceilings. Agents cost more per task than a single model call because they make several, which is exactly why the limits matter.

How do we know it behaves?

An evaluation suite covering normal cases and deliberately adversarial ones, run before launch and again after any change. Combined with the audit trail, that gives you both prediction and hindsight.

[ Let's talk ]

Tell me what you're building.

Describe it in a few lines and you'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually build it.