Capability 01

Agents that do the work.

Production agentic systems — planning, tool use, evaluation and human escalation, wired into the platforms you already run.

Overview

Most agent projects stall at the demo. A model that calls a tool in a notebook is not a system your operations can depend on, and the gap between the two is not the model — it is everything around it. Retries and idempotency. Permissioning. Evaluation. Escalation when the agent is out of its depth. Traces that show what it actually did, and a ceiling on what it can spend getting there.

We build agents that run against real systems with real consequences. That means starting from the task rather than the technology: what the agent is allowed to touch, what it must never do, how it proves it did the right thing, and how a person takes over when it cannot. Get those four answers right and the model becomes an implementation detail you can swap.

What we build

The things you actually receive.

Concrete deliverables rather than adjectives — this is the work, itemised.

01

Tool & API orchestration

Agents that act on your systems through typed, permissioned interfaces — every call authorised, every effect logged.

02

Retrieval pipelines

Grounding on your own corpus: chunking, indexing, freshness policy, and citations that point back to source.

03

Evaluation harnesses

Regression suites for non-deterministic systems, so a change is measured rather than hoped about.

04

Guardrails & policy

Allowed actions, spend ceilings and refusal paths enforced in code, outside the prompt where they cannot be talked around.

05

Human-in-the-loop

Approval queues, escalation and takeover — a person can always intervene, and the agent knows when to ask.

06

Tracing & cost control

Per-run traces, token and latency budgets, and dashboards showing what ran, what it cost and what it changed.

How we approach it

Where this discipline goes wrong.

Four decisions that separate work which lasts from work that has to be redone.

Step 01

Scope the blast radius

Before choosing a model we decide what the agent may touch. An agent that can only read is a different risk proposition from one that can move money, and the architecture follows from that.

Step 02

Ground it first

Retrieval and tools before tuning. A well-grounded modest model beats an ungrounded frontier one on almost every real task, and costs a fraction to run.

Step 03

Build the evals before the agent

We write the evaluation set first. Without one you cannot distinguish a genuine improvement from a lucky sample, and every change becomes an argument.

Step 04

Ship with a brake

Escalation paths, rate and spend limits, full tracing, and a switch that stops it. Nothing goes live that cannot be stopped by someone who is not an engineer.

Engagement

How this one is usually run.

The same engineering practice applies at every size. What changes is the shape of the team.

Good fit

Focused Build

One application or integration, defined scope and price.

Good fit

Product Team

A full delivery team owning the product end to end.

Less common

Enterprise & Government

Multi-team delivery against audit and procurement requirements.

Typically 3 to 6 months to a production agent, with the first working slice in weeks rather than quarters.

Typically built with

  • LLM orchestration
  • Vector search
  • Eval harnesses
  • RAG pipelines
  • MCP tooling
  • OpenTelemetry
  • Python
  • TypeScript
Questions

The ones worth asking.

Including the answers that lose us work — those are the ones worth publishing.

Is this just a chatbot?
No. A chatbot answers; an agent acts. The systems we build take actions in your platforms — creating records, moving work through a queue, calling your APIs — under explicit permissions and with an audit trail. A conversational interface is optional, and often the wrong one.
How do you stop it doing something harmful?
Constraints live in code, not in the prompt. The agent can only reach tools it has been granted, each with its own authorisation; there are spend and rate ceilings; destructive actions route to an approval queue. Prompt-level instructions are a preference, not a control, and we never treat them as one.
Which model do you use?
Whichever fits the task, and we build so it can be changed. Model choice is the most volatile part of this field — anything architected around one provider's quirks becomes a liability within a year. Routing, prompts and evals sit behind an interface so a swap is a configuration change.
How do you know it is getting better?
The evaluation harness. Every change runs against a fixed set of cases with scored outputs, so improvement is a number rather than an impression. This matters more here than in ordinary software, because the same input can produce different output on consecutive runs.
What does it cost to run?
It depends on volume, model and how much grounding each task needs — but we instrument cost per run from the first deployment, and set budgets that cap it. Most of our optimisation work is reducing tokens per task rather than negotiating rates.
Can it run on our own infrastructure?
Yes. If you have data residency or regulatory constraints, the pipeline can run entirely within your cloud accounts, including self-hosted models. That constrains model choice and usually costs more, so we would want to confirm the requirement is real before designing around it.
Get in touch

Let's talk about agentic systems.

Tell us what you're trying to ship. We'll tell you honestly whether we're the right team for it — and what it would take.

Prefer email? info@triyant.sg

We reply within one business day. Your details are used only to respond to this enquiry and are never shared with third parties.