Service
AI Agents and Assistants
We build assistants that act inside your systems: reading records, calling your APIs, drafting work for review, and stopping at the boundaries you set.
The problem
What usually goes wrong
A chat window bolted onto a website answers questions about the website. It cannot tell a customer where their order is, book them in, or update a record, because it has no access to anything.
The useful version is an agent with tools. It reads your data, calls your endpoints, and takes actions that have consequences. That is also what makes it risky, so the interesting engineering is in the constraints rather than the prompt.
We build agents that are scoped, logged and reversible, and that hand work to a person at the points where a wrong answer would cost something.
Scope
What we deliver
Tool definitions against your systems
Each action the agent can take is a typed function with validated arguments, run through the same permission checks as the rest of your application.
Retrieval over your own content
Product data, policies, past tickets and documentation are indexed so answers cite your material rather than the open internet.
Conversation and task memory
State persists across a session and, where it helps, across sessions, so the assistant does not ask the same question twice.
Human in the loop steps
Drafts, approvals and escalations are first class. The agent can prepare a refund, a reply or a schedule change and hold it for a person to release.
Guardrails and refusal behaviour
Topic boundaries, spend limits, record scoping and rate limits are enforced in code, not asked for in a prompt.
Transcript logging and evaluation
Every exchange and tool call is recorded so you can audit what happened and measure changes against a fixed set of real cases.
Method
Technical approach
The agent is an application, not a prompt. Tools are typed, arguments are validated with a schema, and the same authorisation layer that protects your API protects the agent calling it.
Retrieval is built around how your documents are actually structured. Chunking follows headings and record boundaries rather than a fixed character count, and each chunk keeps the metadata needed to filter by customer, product or date.
We separate reading from writing. Read tools are broad and cheap. Write tools are narrow, idempotent, and where the action has a cost they produce a proposal a person confirms.
Failure paths are designed. Timeouts, provider errors and low confidence answers route to a fallback: a shorter deterministic reply, a handoff, or a queued task, never a hallucinated fact.
Evaluation runs on a set of real cases collected from your business. Prompt and model changes are compared against that set before they ship, so quality is a measurement rather than an impression.
Handover
Deliverables
Everything below is yours at delivery, including the intellectual property. Sawhorse keeps nothing.
- 01Agent service with typed tool definitions bound to your systems
- 02Retrieval index over your documents with metadata filtering
- 03Conversation store and session handling
- 04Approval and escalation flows where actions carry cost
- 05Guardrail layer covering scope, spend and rate limits
- 06Transcript and tool call logging with a review interface
- 07Evaluation set and a script to run it
- 08Source code, deployment guide and operating documentation
Related
Systems this service builds
- AI Agents and AssistantsAssistants embedded in your product or operation that answer from your data, take scoped actions through typed tools, and escalate to a person when they should.
- Customer and Client PortalsA logged in area where your customers see their own status, documents, invoices and history, which removes the phone calls that only exist because they cannot.
- Workflow Automation PlatformsAn orchestration layer that runs your cross system processes with retries, visibility and controls, instead of scripts on a laptop and rules in one person email client.
FAQ
Questions people actually ask
Can the agent change records in our CRM?
Yes, where you want it to. Write access is granted tool by tool, scoped to specific record types and fields, and can be set to produce a change for a person to approve instead of applying it directly.
How do you stop it answering things it should not?
Scope is enforced outside the model. Retrieval is filtered to the material the user is allowed to see, tools refuse arguments outside their permitted range, and out of scope requests route to a fixed response or a handoff.
What happens when the model provider has an outage?
The agent degrades rather than breaks. Requests fail over to a secondary model where the use case allows it, and otherwise return a deterministic response and queue the task.
Can it run on a private model?
Yes. Where data cannot leave your environment we design against a private or on device model and keep retrieval inside the network. The tradeoffs in latency and quality are written into the plan before you decide.
How do you measure whether it is any good?
With an evaluation set built from your real cases and expected outcomes. Changes are scored against it, so you get a number rather than a demonstration.
Do we own the agent?
Yes. The source code, the prompts, the tool definitions, the evaluation set and the documentation are all yours at delivery.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.