Service · published 23 Aug 2026
AI agents with guardrails you can audit.
We build agents that answer from live operational data, and we run agents on our own business — with hard caps, kill switches, and a human owning every consequential action. The guardrails are code, not prompts.
AI agent development is building systems where a language model plans and calls tools — APIs, databases, documents, browsers — to complete multi-step work, with the engineering weight carried by tool design, deterministic guardrails, and evaluation rather than by the model alone.
Agents over live systems
Our aviation assistant calls tools against live data — flight history, crew availability, legality checks — and renders results as tables and charts, with every operational claim traceable to the system of record. The engineering that makes this trustworthy: typed tool interfaces, per-interaction tracing down to each tool call and its cost, and structured outputs instead of free-text parsing.
The rails matter more than the model
Our own sales-pipeline agents run 24/7 with deterministic Python enforcing what the LLM cannot override: daily caps stored in restart-surviving state, suppression lists, compliance checks that refuse to run when required information is missing, and a kill switch the automation triggers itself on any anomaly. We also built a closed-loop optimization harness that improved an agent's tool-selection eval score from 59% to 72.4% across twenty accept/reject-gated iterations — with deterministic grading, not an LLM judging itself.
Questions we actually get
- What is an AI agent, practically?
- A language model given tools and a goal, looping until the work is done: read the ticket, query the database, draft the response, file the update. The practical definition matters because the hard parts aren't the model — they're tool design, failure handling, guardrails, and knowing when a human must own the action.
- How do you keep an autonomous agent safe?
- Deterministic rails outside the model's reach: hard limits enforced in code and database state, allow-listed actions, suppression rules, and kill switches — including ones the system triggers itself when it encounters anything unexpected. In our own agents, anything identity-bearing or irreversible queues for a human. Prompts are instructions; rails are physics.
- How do you evaluate whether an agent actually works?
- With an eval harness before production and tracing after: a fixed scenario set scored on tool selection, output content, and completion — deterministically where possible. We've run closed-loop improvement against such a harness, lifting tool-selection accuracy from 59% to 72.4% over twenty gated iterations. If a vendor can't show you their agent's eval scores, they don't know if it works either.
- Which framework do you use — LangChain, CrewAI, something else?
- Usually none. Production agent loops are a few hundred lines of code you fully control; frameworks add abstraction where you most need transparency. We use provider SDKs directly, typed tool schemas, and our own tracing. The framework question matters far less than the tool-design and evaluation questions.
- What's a realistic first agent project?
- One workflow with clear inputs, a bounded action space, and measurable output — document triage, monitored-source summarization, research-and-draft pipelines where a person sends. Full autonomy over consequential actions is where agent projects die; a draft-for-human-review agent ships in weeks and builds the evidence for expanding autonomy.
- Do you build customer-facing agents too?
- Yes — nowreply, our own live product, is a customer-facing agent: it answers inquiries from a business's documents and calendar and books appointments, multi-tenant, with 755 backend tests behind it. The same platform patterns apply to client builds.
The fastest way to find out if this fits: a free audit on one workflow — an honest answer on whether it's worth building, and a written summary you keep either way.