Custom Agents
AI Process Design
One process, written down: what the agent does, what a human approves, what gets logged.
Available now · Human approval · Complete audit trail
The operational problem
The process in people’s heads cannot be tested
Operational work usually contains exceptions, informal approvals and judgement that a flowchart misses. Building an agent from the happy path simply moves those hidden decisions into prompts.
Process Design works with the people who run the task today. It defines inputs, decisions, tools, permissions, approval points, failure behaviour and acceptance scenarios before implementation begins.
Specification scope
What must be decided before an agent is built
Trigger and outcome
The event that starts the work and the observable result that marks it complete.
Decision rules
The facts, thresholds and exceptions that change the next step.
System operations
Required reads and writes expressed as named tool operations rather than broad access.
Human gates
The person, exact decision and evidence shown before a consequential action.
Acceptance and failure
Normal, edge, refusal and recovery scenarios that the later build must pass.
Design method
How operational knowledge becomes a testable specification
- Walk through real workThe people who perform the process demonstrate recent normal and exceptional cases.
- Name state and decisionsInputs, intermediate states, business rules and completion evidence are made explicit.
- Separate reads from writesEvery required system operation receives a risk class and minimum permission.
- Place human gatesApproval belongs immediately before the exact action a person is accountable for.
- Write acceptance scenariosExamples define expected outputs, refusals, logs and recovery behaviour.
- Approve the build contractThe process owner accepts the specification used to scope and judge implementation.
Example specification
Permissions and acceptance stay visible
Illustrative process specification — scope varies by workflow
- Process
- Order-status questions by email
- Allowed operations
- read order, read shipment
- Human approves
- Any refund or change
- Logged
- Every reply
- Acceptance tests
- 12
Design judgement
The rules behind a buildable process
Start with the people doing the work
Documentation is evidence, but current operators reveal the exceptions that decide whether automation is safe.
An approval needs an object
The specification names exactly what the person sees and authorises, not merely that approval happens.
Refusals are designed
Out-of-scope, unsafe and insufficient-evidence cases receive an explicit stop or escalation path.
Acceptance precedes implementation
The build is judged against scenarios agreed before model or framework choices dominate the design.
Fixed start
What the one-week process design delivers
- Current-state process mapTrigger, roles, systems, decisions, exceptions and present hand-offs.
- Agent responsibility boundaryWhat the agent prepares, what it may execute and what remains human work.
- Tool and permission specificationNamed operations, inputs, outputs, credentials and refusals per system.
- Approval and audit modelWho approves which exact action and what evidence is retained.
- Acceptance suiteScenarios the later build must pass, including exceptions and failures.
Fit
When process design is—and is not—ready
A good fit
- One recurring process has an accountable owner and people who can demonstrate it.
- The desired outcome is clear but permissions, exceptions or tests are not yet written.
- You need a vendor-neutral build specification before committing to implementation.
Not the right fit
- The request spans an entire department without one named process or outcome.
- Nobody can own the operating decisions or approve the future behaviour.
- The intended system access cannot be expressed as controlled operations.
Where the human approves
You approve the spec. The AI works through a fixed list of allowed operations; every approval and result is logged.
Design questions
Questions a process owner should ask
Why not begin by building a prototype?
A prototype can hide unclear permissions and exceptions. The specification makes behaviour and acceptance explicit before implementation effort creates momentum around the wrong process.
Who needs to join the design?
The accountable process owner and the people who perform the work today. System owners join where permissions, data or integration behaviour must be decided.
Does the specification choose a model or framework?
Only where a choice is necessary to satisfy an accepted requirement. The primary output describes behaviour, controls and tests rather than locking the process to marketing names.
How detailed are the acceptance scenarios?
Detailed enough to state the input, expected decision, approval, tool result, output and audit evidence for normal and exceptional cases.
Can another supplier build from the specification?
Yes. It is intended to be a concrete build and acceptance contract, not a proprietary discovery document.
Experience behind the service
Built from agents that have to survive production
The method comes from TechOne’s own agent, document and operational systems. It uses process walkthroughs, operation allowlists, human gates and acceptance scenarios before code is accepted.
Technical stewardship: David Máj, Founder & Technology Consultant. Last reviewed 24 September 2026.