Skip to content
ALGOLOGIX

AI engineering

Agentic AI

We build agents that do real work inside your systems — planning a task, calling your tools, and knowing when to stop and ask a person. The hard part is never the loop; it is the guardrails, the evaluation and the handback, and that is the part we spend most of the build on.

  • Multi-agent orchestration
  • Tool use & MCP
  • Human-in-the-loop
  • Guardrails
  • Workflow automation

What we build

Task agents
An agent that completes one bounded job end to end, with a defined handback.
Tool and MCP servers
Your systems exposed as typed tools, reusable across every model and client you run.
Approval and escalation flows
Where a human confirms, what they see when they do, and what happens when they decline.
Guardrails and policy checks
Input and output validation, allowed-action lists, and refusal paths that are tested.
Agent evaluation harness
A scored trajectory suite that gates releases, not a set of prompts someone tried once.

Problems this solves

  • Problem
    The agent works in a demo and does something unexpected on real inputs.
    Approach
    Build an eval set from real traffic, score whole trajectories rather than final answers, and gate every release on it.
    Outcome
    Behaviour changes become measurable, so a regression is caught before a customer finds it.
  • Problem
    Nobody trusts it enough to let it act on anything that matters.
    Approach
    Put a person in the loop at the point of consequence, with a readable trace of what the agent intended and why.
    Outcome
    The agent earns scope gradually, against evidence, instead of being switched off after one bad run.
  • Problem
    Every new tool means another bespoke integration to maintain.
    Approach
    Expose systems once as MCP tools with typed schemas, and let every agent and client share them.
    Outcome
    Adding the next agent is configuration rather than another integration project.

How we approach it

  1. Discover

    We map the job end to end and mark the point where a wrong action costs money. That point becomes the approval step, and everything before it is what the agent is allowed to do on its own.

  2. Design

    Tools first, prompt second. The typed tool surface and the escalation path are designed before any of the reasoning, because an agent is only ever as safe as the actions available to it.

  3. Engineer

    One bounded job, running end to end, inside the first fortnight. Scope grows by adding tools to a loop that already works rather than by widening what the model is asked to decide.

  4. Evaluate & harden

    We score whole trajectories rather than final answers — reaching the right result through three wrong calls is not a pass. Refusal and escalation paths get the same tests as the happy path.

  5. Launch & operate

    Every run is traced, so the first bad one is readable instead of a mystery. Scope widens against that evidence, one action at a time.

What we build it with

Irreversible actions wait for a person and everything else runs. The allow-list is the guardrail, and it is tested like any other branch.

agent/approvals.py
"""Irreversible tools wait for a person. The rest just run."""

from anthropic import Anthropic

client = Anthropic()

# Anything that moves money or deletes something.
NEEDS_APPROVAL = {"issue_refund", "cancel_subscription"}


def handle(block, tools, approvals):
    """One tool call from the model — or a pause for a human."""
    tool = tools[block.name]

    if block.name in NEEDS_APPROVAL:
        return approvals.request(
            action=block.name,
            arguments=block.input,
            shown_to_user=tool.summarise(block.input),
        )

    return tool.run(**block.input)


response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    tools=[tool.schema for tool in tools.values()],
    messages=messages,
)

results = [
    handle(block, tools, approvals)
    for block in response.content
    if block.type == "tool_use"
]

Languages

  • Python

AI models & providers

  • Anthropic Claude

Agent & LLM frameworks

  • LangGraph
  • Model Context Protocol
  • Anthropic Agent SDK
  • Temporal

Observability & evaluation

  • LangSmith
  • OpenTelemetry
The full inventory

Related work

  • Logistics · 2026

    A voice agent that handles the overnight queue

    An inbound voice agent for a freight operator, handling status enquiries and booking amendments outside staffed hours, with a clean handover into the morning queue.

    Overnight calls handled without a person
    • conversational voice ai
    • agentic ai
    • backend apis
    Read a voice agent that handles the overnight queue

Questions we get asked

How is this different from a chatbot with a few functions bolted on?

A chatbot answers. An agent plans a sequence of actions, calls real systems, checks its own work and escalates when it should not proceed. The engineering that matters is the part after the model call — retries, idempotency, permissions and the handback to a person.

How do you stop it doing something expensive or irreversible?

Irreversible actions sit behind an explicit approval step, tools carry allowed-action lists and least-privilege credentials, and every run has a cost ceiling. We test the refusal paths the same way we test the happy path.

Which model do you use?

Whichever scores best on your evaluation set for the task, at a latency and cost you have agreed. We build behind an abstraction so switching is a configuration change, and we re-run the evals when a new model ships.

Can it work with our existing internal tools?

Yes — that is usually the point. We wrap your APIs, databases and internal services as typed tools, most often over MCP so they are reusable, and we scope credentials per tool rather than handing an agent a master key.

Tell us what you are trying to ship.

A first call is 30 minutes and costs nothing. Bring the problem rather than a spec — the useful part is usually working out whether this is the right shape of solution at all.