THE TRIGGER
For teams building customer-service AI
Know what your AI agent is ready to handle next.
An independent review of the customer-service workflow you want to expand—from answering customers to changing orders or bookings. I examine conversations, actions and system design, and give your team reproducible findings, prioritized changes and checks to support the next rollout.
The engagement, at a glance
Goes in
One workflow to expand
Customer requests, permitted actions and handoffs.
System access
Conversations, action results, the relevant code and configuration.
I REVIEW · TWO LENSES
Behaviour
What the agent tells customers, what it changes, and when it hands over.
Design
How instructions, knowledge, permissions and integrations shape that behavior.
Trace the behavior back to the system.
Comes out
- Workflow findings, with evidenceDocument
- Design findingsDocument
- Roadmap for the next rolloutDocument
- Rollout gates and regression checksCode + cases
- Executive summaryPresentation
Two to three weeks
A review in practice
Fictional scenario, real failure patterns
01 · THE DOUBT
The exceptions don’t add up.
Routine refunds pass. Reports of a duplicate payment and inconsistent handoffs prove hard to reproduce.
The team brings me in to investigate the anomalies and establish what evidence they need before expanding.
02 · THE DISCOVERY
A repeatable failure emerges.
I use conversation patterns and design notes to identify likely weak points, then run targeted cases against the agent. After several iterations, the discovery:
A refund succeeds, but its response is lost. On restart, a new identity lets it pass duplicate protection again.
Also found: repeat conversations bypass cumulative limits; pending refunds are reported as completed.
03 · THE NEXT STEP
Clear conditions for expansion.
With engineering, we define changes to refund identity, account limits and payment status. Each finding gets a repeatable check.
Unresolved paths stay with a person. The rollout decision rests on specific evidence, with the gaps recorded.
Showing the trigger.
How it runs
Two to three weeks
Agree scope
Before the review
Scope and directionBeforeDefine the next expansion and the evidence needed to decide.
We agree what you want the agent to handle next, what it must get right, and what the review needs to establish. Then we set the scope, access, terms and fixed fee.
Investigate
Evidence and design inform each other.
Map the workflowDays 1–2Map the system, record hypotheses and preserve the evidence.
I trace the workflow through instructions, knowledge, actions and handoffs. We record the version under review and the team’s hypotheses, then preserve the evidence needed to test them.
What it does todayWeeks 1–2Examine conversations and action results, then probe likely weak points.
With criteria agreed with your domain expert, I use output patterns and design hypotheses to build targeted cases. Each round informs the next as I test for failures beyond those already reported.
How it is builtWeeks 1–2Trace failures to system design and test its limits for expansion.
I trace findings to their causes and examine design assumptions the proposed expansion depends on. That analysis shapes further tests; their results refine the design findings.
If something critical turns up: we discuss it the same day.
Prepare the next step
Priorities, checks and handover
Prioritize changesWeek 2Agree what to change first and how to verify each change.
We separate blockers to the next rollout from improvements that can follow. The people who will own the changes review the priorities and the evidence needed to verify them.
Hand over the checksWeeks 2–3Package the tested cases so your team can rerun and maintain them.
I turn the investigation’s cases into repeatable rollout and regression checks, including blockers that still fail. Your team runs them with me, then takes ownership of maintaining them.
Readout and handoverFinal daysPresent the findings, conditions for expansion and remaining gaps.
I verify the findings and share them with the people involved before the executive presentation. We discuss the rollout recommendation, remaining uncertainty and conditions to meet, then complete the handover.
What you get
Illustrative excerpts · Refund review
Executive summary
The recommendation, its evidence and the conditions for the next rollout.
Workflow findings, with evidence
A finding inventory linked to evidence and runnable reproduction cases.
F01 · FINDING 1 OF 3
One approved refund is paid twice.
The payment succeeds, its response is lost, and the agent restarts. A new payment key lets the same refund pass duplicate protection again.
- Evidence
- Action trace + payment records
- Reproduce
- A runnable case with the starting state, injected failure and payment assertions.
Design findings
System maps, failure mechanisms and constraints on the next expansion.
D01 · SELECTED DESIGN FINDING
The refund’s identity changes at restart.
The refund tool derives its payment key from the current run. After a restart, the same approved refund gets a new key.
- Requirement
- Persist and reuse a key for the approved refund across executions.
- Verify with
- Lost response + restart
Roadmap for the next rollout
An ordered plan for this expansion, with owners and verification conditions.
R01 · BEFORE EXPANSION
Give each approved refund a durable identity.
Persist the payment key before the first attempt. Reconcile uncertain results before retrying.
- Owner
- Payments integration team
- Verified when
- A lost response and restart still produce only one payment.
R02–R03 · Account limits and payment status
Re-run the suite on the release candidate.
Rollout gates and regression checks
A runnable handover: cases that block expansion and checks for what already works.
gates/
regression/
approved.yamlhandoff.yamlfixtures/
payments.tsrun-checks.tsREADME.mdgates / lost-response.yaml
# Simplified example · linked to F01 / R01 id: G01 fixture: approved_refund fault: after: payment_committed inject: response_lost recover: restart_workflow assert: payments_for_refund: 1 state: completed
# Simplified example · linked to F02 / R02 id: G02 fixture: customer_account account: cap: 100 refunded: 80 new_conversation: true refund_request: 30 assert: excess_refund: blocked new_payments: 0 account_total: 80
# Simplified example · linked to F03 / R03 id: G03 fixture: approved_refund provider_result: pending assert: recorded_state: pending customer_message: claims_completed: false
$ npx tsx run-checks.ts
PASSregression/ · 2 cases
FAILG01 · lost response
FAILG02 · account cap
FAILG03 · pending status
G01 · Duplicate payment
Expected 1 payment; observed 2.
Expected 1 payment; observed 2.
G02 · Account limit bypassed
80 already refunded + 30 requested exceeds the cap of 100. Expected blocked; observed paid.
80 already refunded + 30 requested exceeds the cap of 100. Expected blocked; observed paid.
G03 · Incorrect payment status
Provider status: pending. Customer message: completed.
Provider status: pending. Customer message: completed.
Cases, fixtures and runner are handed over together. Your team reruns the failing gates after changes and keeps them as regression checks.
Who runs it
Dragos Bilaniuc
Software engineer & architect
Cluj-Napoca, RO · Remote
Over nine years in software delivery, across engineering, architecture and technical leadership.
My work on AI reliability looks at how agent behaviour, system design and testing fit together to reveal failures and establish what’s ready to roll out.
I run every review myself, from the first call to the handoff.
WHAT TEAMS SAY
“Before diving into the code, he takes the time to thoroughly understand the business requirements — that meticulous upfront analysis lets him anticipate complex edge cases and architectural roadblocks long before they reach production.”
Questions
Your team brings the domain expertise, product knowledge and experience of running the system. I bring depth in AI reliability and system design. We build on your existing evaluations, examine how the agent and its integrations behave together, and turn the findings into checks for your next rollout.
Both. The review can support a first release, an expansion or an investigation into inconsistent behaviour. We need a runnable workflow and a concrete decision to examine; the scope reflects what you’ve built and what you want to enable next.
A technical counterpart, the relevant policies, code and configuration, and access to conversations, action results and a suitable test environment. We establish the access, evidence gaps and expected involvement before agreeing the scope.
We agree access, testing boundaries, processing tools and retention before work starts. Testing uses an isolated environment, with synthetic or redacted records where practical. Your material remains confidential, and nothing is published without your permission.
A fixed fee for an agreed scope, quoted after the first conversation. The proposal sets out the workflow, decision, deliverables and responsibilities before you commit.
Your team implements the product changes. I hand over the roadmap and runnable checks, and walk your engineers through using them to verify fixes. Any implementation support or further review is agreed separately.
I report that plainly. You still receive the evidence from the agreed scope, reusable checks and the remaining uncertainties. Those results support your rollout decision within the boundaries of what we examined.
Let’s talk
What do you want your agent to handle next?
Let’s discuss your customer-service workflow, what your team is preparing to change, and where confidence is missing. We’ll work out whether a review would help and what it should focus on.
No preparation or system access needed.
Prefer email? Send me a sentence about the workflow.
dragos@dbln.meDiscuss your AI workflow
30 min · Google Meet
The calendar loads from Cal.com when you click. Privacy notice