From a first call to a delivered system

Most of the projects I have delivered at Kuzushi Labs began with a sentence that was too large to build. "We want an AI agent for our calls." "We need one assistant that knows everything in the company." The customer is rarely wrong about the need. The sentence simply has not yet been turned into a workflow, a boundary and a test.

Choosing a framework has never been the hardest part. The hardest part is deciding what problem the system should solve, what must stay in the customer's existing software, and what evidence will show that the work was useful. This page describes how I take a project from that first sentence to a system the customer's team can run. The same six phases have carried a telephony voice agent and an enterprise RAG assistant, and I use both as worked examples below.

The six phases

Each phase answers one question and leaves one artifact. The artifact matters more than the meeting. A customer can read it, disagree with it and sign it off, and the next phase starts from something written down.

The arrows that point backwards are part of the method. A build that uncovers a new constraint goes back to scope. A delivered journey becomes the starting point for scoping the next one.

1. Discover: find the business decision

The first meeting should produce something more concrete than "an AI sales agent." I am looking for the workflow as it runs today, who owns it, and what happens at the end of it.

These are the questions I keep returning to:

• What starts this task, and who is doing it today?
• What does the person need to know before they can finish it?
• Which facts have to be checked in another system?
• What is the system allowed to change, and what must it only recommend?
• What should be handed to a human, and what does that person need to receive?
• How would you know, a month after launch, that this worked?

The answers usually change the request. Here is how two of them changed.

In the voice engagement, that difference decided the architecture. A lead qualification needs a record the next team can act on. An appointment needs the details a scheduler requires. A polite transcript proves neither. In the knowledge assistant, the important discovery was that "who may see this" had to be answered before "how do we retrieve this." A synthesized answer can hide where its information came from, so the boundary had to sit inside the answer path.

I write the outcome as a short problem statement in the customer's own vocabulary. If they would not recognise it as their problem, discovery is not finished.

2. Constrain: budget, timeline, people and access

Requirements describe what the customer wants. Constraints describe what the project can actually be. I collect them before proposing a solution, because a solution that ignores them is a slide, and the customer has usually seen enough of those.

I sort every constraint into one of three columns:

constraint_sheet:
  fixed:        # the project is shaped around these
    - budget envelope for the first release
    - launch date or the event behind it
    - systems we must integrate with, as they are
    - compliance and data-residency rules
  flexible:     # these absorb the pressure
    - number of workflows in the first release
    - channels and languages at launch
    - depth of the operator tooling
  unknown:      # each one gets an owner and a date
    - when we receive data and API access
    - real call or query volume
    - quality of the source documents

Budget. I ask for the range early and directly. It is an engineering input. A three-person team for three months builds a different first release from a larger team for a year, and it is better to design for the real number than to discover it in the proposal review. When the budget and the date are fixed, the scope is what moves.

Timeline. I ask what the date is attached to: a pilot customer, a funding conversation, a season. The client calling platform ran from October 2024 to January 2025 with a team of three. Zoice, our own platform, ran from July to September 2025 with a team of three. Windows of that size rule out building every layer from scratch, which is a useful thing to know in week one.

Access. In enterprise work, the longest lead time is often permission: a service account, a data extract, a security review. The knowledge assistant had to read from Oracle Fusion, CMiC, Hyperion and SharePoint, and deliver inside Microsoft Teams. Each of those is an integration with an owner. Every item in the unknown column gets a name and a date, because an unowned unknown becomes a delay in month two.

Targets and measurements. A target is written down as a target. The voice platform had a sub-second response objective with an 800 ms preferred budget. The delivered system measured approximately 1.1 seconds in early 2025. Both numbers are useful, and they are different kinds of number. Keeping them apart from the first document prevents a design goal from quietly turning into a claim.

3. Scope: the smallest complete journey

A useful first release handles one complete journey, including its failures. For a calling agent, that might be an eligible enquiry through to a verified callback, with corrections, silence, disconnection and handoff inside that journey. It does not need to answer every question that can be asked over a telephone.

The scope is recorded as a contract. I use the same seven questions for every project:

Then I write acceptance examples. A requirement such as "understands Hinglish" or "respects permissions" is difficult to accept or reject. An example is not:

Given: an employee asks for the budget variance of a project
When: their identity has no access to that project's financials
Then: no rows from that project are retrieved
And: the assistant says it cannot answer, and why
And: no figure from that project appears in the reply

The negative assertions matter. "The assistant replied politely" would pass a system that also leaked the number.

Build, fork or buy. Scope is also where I decide what not to write. For the client calling platform, we forked and modified Bolna and used Plivo for telephony, because the window was short and the call lifecycle was the customer's risk, and an orchestration framework was somebody else's solved problem. For Zoice, with a product to maintain, we built on Pipecat and made providers, agents and pipelines configurable. The same team made two different choices because the constraints were different.

Milestones. A plan is a list of things the customer will be able to see. This is an illustrative shape for a twelve-week, three-person engagement, and the real dates come from the constraint sheet:

Change. New requests arrive in every project, and many of them are good. My rule is simple: a new request is welcome, and it displaces something. We look at the milestone table together and decide what moves. That conversation is much easier when the scope contract already has an "explicitly out" row.

4. Build: a thin slice on real inputs

I build the narrowest path that crosses every boundary first: real telephony into real recognition into a real model and back out as audio; or a real employee identity into a real retrieval and back into Teams. It is unimpressive for about two weeks. It also finds the integration problems while there is still time to re-scope.

Three habits carry this phase.

Real inputs early. Synthetic test calls are clean. Real callers interrupt, switch between Hindi and English mid-sentence and go silent. Real enterprise documents have nested tables and three versions of the same policy. The sooner the system meets them, the more honest the plan becomes.

Instrument by stage. On the voice platform we captured recognition timing, first model output and first synthesis output separately, so a slow turn could be investigated by stage. Without that, "it feels slow" has no owner. The same applies to retrieval: whether the right source was found, whether the answer represented it faithfully and whether the citation leads to the passage are three separate measurements.

A demo every week, and a decision log. The demo is the customer's chance to correct direction while it is cheap. The decision log records what we chose, what we rejected and what would make us revisit it:

decision: coordinate barge-in with the carrier's playback buffer
context: caller interrupts while generated audio is still queued at the carrier
options:
  - cancel the model request only
  - cancel generation, synthesis and local queues
  - the above, plus a clearAudio event to the carrier
chosen: the third option
cost: call state and the telephony protocol must agree on which response is current
revisit_when: the carrier or framework exposes playback acknowledgements

That entry is written from a real decision on the client platform. Interruption turned out to be a system event, and treating it as a single cancelled request left stale audio playing to the caller.

5. Evaluate: the release decision

The acceptance examples from the scope phase become the regression set. Every defect found in a demo or a pilot call is added to it. By the time a release is proposed, the customer is looking at the same examples they agreed to in week two, plus every failure we have met since.

I keep three kinds of result apart:

A lower latency is not automatically staff hours saved, and forty simultaneous calls are not forty jobs replaced. When the business outcome has not been instrumented, I say that, and report the delivery milestone and the technical result. For a retrieval system I want to see three demonstrations before release: a permitted answer, a refusal, and a stale-data case.

This is also where a project can honestly pause. In September 2026 I ran a public-data Hinglish fine-tuning experiment where normalized word error rate fell from 215.62% to 77.29%. That is a large improvement and still far too high for a customer deployment, and the write-up says so. An evaluation that can only say yes is not an evaluation.

6. Deliver: make it theirs

A system is delivered when the customer's team can deploy it, observe it and recover it. For the voice platforms that meant containers on Kubernetes, call sessions that clean up after themselves, and call records that the next person or system in the workflow can use. For the knowledge assistant it meant living inside Microsoft Teams, where the employees already work, with access enforced from their Azure AD identity.

The handover package is small and specific:

• how to deploy, roll back and rotate credentials
• what each dashboard and alert means, and what to do about it
• the regression set, and how to add an example to it
• the decision log, so the next engineer knows why things are the way they are
• the known limits, written plainly

At Kuzushi Labs we stay close for a post-launch window of thirty days. Most of what is learned in that month comes from real usage, and it goes back into the regression set and the scope for the next journey.

Delivery also produces something for the next customer. The client calling platform taught us where voice systems actually break: interruption, endpointing, provider differences and call cleanup. Zoice was built with those lessons expressed as configuration, so a persona, a voice or a provider could change without editing transport code. Reusable patterns are the difference between the tenth engagement and the first.

The same method, two engagements

The engineering is described in the case studies: the client voice platform, Zoice, the enterprise knowledge assistant and the client equity research platform. The twelve-part conversational AI series goes deeper on each voice decision, beginning with the discovery session and ending with cost and business impact.

Where the method bends

A startup and an enterprise need different amounts of it. With a three-person startup, discovery can be two conversations and the scope contract a single page. In an enterprise, the constraint sheet is the project: access, security review and the number of people who must agree. The phases stay the same. The time spent in each one changes.

Sometimes the right answer is a smaller system. If a rule, a form or a better search box solves the workflow, I would rather say so in week one. Trust from that conversation is worth more than the larger project.

Some things cannot be promised. I can commit to a journey, a date and a measured result. I cannot commit to a conversion rate before a cohort exists. When a customer needs a number I do not have, the plan includes the experiment that would produce it.

Contribution

At Kuzushi Labs I have worked across the customer and the engineering side of these engagements: sales discovery, requirements and scope, architecture, hands-on development and delivery, usually in a team of three. This page describes the way of working that came out of that. The individual case studies show what it produced.

FIELD: the full engagement methodology

FIELD is the Kuzushi Labs methodology for evaluating and scoping client work. It formalizes the connections between customer value, workflow discovery, engineering, release evidence and enduring ownership. The five stages group discovery under Frame and Investigate, scope and build under Engineer, evaluation under Launch, and handover and ongoing improvement under Develop.

The practical handbook adds readiness, commercial commitments, unit economics, authority, adoption and exit planning. The 36 worked applications demonstrate the method with explicit planning assumptions. Use the assessment workbench and editable kit to apply it to an engagement.