Custom Agents
AI Agent Build
A working agent on your process, delivered with tests and a runbook.
Available now · Human approval · Complete audit trail
The operational problem
A working demo is not a system you can operate
An agent becomes operational only when its job, permitted tools, approval points, failure behaviour and acceptance criteria are explicit. Without those boundaries, a fluent answer can hide an untestable process.
We build from an approved process specification and tool contracts. The agent is tested against the scenarios you accepted, handed over with its code and runbook, and designed to refuse operations outside its allowed list.
Build scope
What a production-ready agent includes
Approved specification
The process, inputs, outputs, approval points and acceptance criteria are agreed before implementation.
Tool contracts
Each connected system exposes a short list of named operations with defined inputs, outputs and refusals.
Human gates
Actions that change something stop with the exact proposed action visible to the accountable person.
Acceptance suite
Normal cases, edge cases, refusals and failure paths are repeatable tests—not memories from a demo.
Operational handover
Code, configuration, tests and a runbook explain how to deploy, observe, recover and change the agent.
Delivery method
How an approved specification becomes a working agent
- Freeze the accepted behaviourThe approved specification becomes the baseline for scope and acceptance, including what the agent must refuse.
- Connect only required operationsExisting or new connectors expose the minimum reads and writes the process needs.
- Implement the decision flowThe agent coordinates tools, evidence, state and human gates around the agreed process.
- Exercise failures as well as successesTests cover missing data, unavailable tools, denied operations and rejected approvals, not only the happy path.
- Run the acceptance scenariosThe same named scenarios are rerun until the agreed results, refusals and logs are visible.
- Hand over something operableYou receive the code, test suite and runbook, with a clear choice of who operates the agent next.
Example handover
Acceptance is visible, not implied
Illustrative acceptance handover — scope varies by process
- Scenarios
- 12 of 12 passed
- Approval points
- 2, working
- Runbook
- 9 pages
- Handover
- Scheduled
- Operations
- Ours or yours
Engineering discipline
The rules behind a controllable agent
Permissions live in tools, not prose
A prompt saying “do not delete” is not a control. A connector that has no delete operation is.
The exact action is approved
The reviewer sees the message, change or record as it will be executed—never only a friendly summary.
A refusal is a testable result
Out-of-scope and unsafe requests must fail predictably and leave evidence in the log.
Operations are part of the build
Monitoring, backup, recovery, configuration and ownership are documented before handover.
Fixed start
What the two-week build delivers
- Working agentThe accepted process runs through the required tools and human approval points in the agreed environment.
- Tool permission mapAllowed operations, denied operations, credentials and approval requirements are documented per connector.
- Acceptance test suiteNamed scenarios cover expected results, boundary cases, refusals and operational failures.
- Audit and refusal evidenceThe handover shows what ran, what waited for approval and what the system refused.
- Code and runbookThe implementation, tests and operating instructions are yours rather than hidden behind a demonstration.
Fit
When a custom agent is—and is not—ready to build
A good fit
- One process already has an approved specification, accountable owner and testable outcome.
- The required systems can expose supported operations through APIs, connectors or controlled tools.
- Your team wants a maintainable implementation with code, tests and operating documentation.
Not the right fit
- The process changes with every person and nobody can approve a common operating rule.
- The request is still “build us an AI” without a named task, owner or acceptance criteria.
- Critical systems can only be accessed through unrestricted administrator credentials.
Where the human approves
You accept the handover. The AI works through a fixed list of allowed operations; every approval and result is logged.
Architecture and ownership
Questions a technical buyer should ask
What must exist before the two-week build starts?
An approved process specification, named acceptance scenarios and access to the required tool connectors. If those do not exist, AI Process Design or a connector build is the correct first step.
Do we receive the source code?
Yes. The agreed implementation, configuration, tests and runbook are included in the handover. External platform licences or third-party services remain subject to their own terms.
Can the agent act without human approval?
Read-only preparation can run within its defined tools. Actions that change something stop at the agreed gate; destructive actions require a second approver.
How do you prevent the agent from calling an unsafe operation?
The connector exposes only the named operations in its contract and rejects everything else. This boundary is tested independently of the model’s instructions.
What happens when a tool or model is unavailable?
The expected failure behaviour is part of the acceptance suite and runbook. The agent must stop or degrade visibly, preserve state and avoid repeating a write blindly.
Who operates the agent after handover?
It can run in your environment under your team or move into a separate Agent Operations service. Ownership, monitoring and recovery responsibilities are made explicit at handover.
Experience behind the service
Built the same way we build our own products
The build method comes from TechOne’s own product and agent work: multi-agent development roles, whitelisted system tools, cited research, and operational connectors for deployment, services, backups and TLS. We expose the architecture, tests and runbook without exposing customer systems or internal commercial data.
Technical stewardship: David Máj, Founder & Technology Consultant. Last reviewed 24 September 2026.