How We Work
Most businesses don't run on processes. They run on the memory, patience, and improvisation of the people who patch the processes together. Someone re-keys a spreadsheet into a CRM. Someone chases a Slack thread to find the version of a document that got approved. Someone spends Monday morning cleaning up what should have finished on its own on Friday. It works, until it doesn't, and by the time it visibly breaks the friction has already cost you a quarter's worth of energy.
Adding "an AI" to that picture without a method usually makes it worse. You get a shiny assistant that answers questions no one asked, sitting on top of the same broken workflow. Ithonga treats each engagement like a proper build project instead. Six stages, in order, with a clear handover between each. The point isn't to be exhaustive for its own sake; it's to make sure the workflow that goes live is one you can run your business on, not a demo you have to babysit.
1. Discovery
Discovery is where we work out which processes are worth touching in the first place. We spend time with the people actually doing the work, not just the people who commissioned the project. That means structured interviews with operators, shadowing sessions where we watch a task happen live, and a workflow map that captures the real path a piece of work takes rather than the tidy version on the org chart.
By the end of Discovery you have a short list of candidate processes ranked by two things: how much friction they generate today and how tractable they are to orchestrate. Something that costs your team ten hours a week and lives in one system is a very different candidate to something that costs two hours a week and touches five. We're upfront about the ones that aren't a fit, and about which pain points sit outside our scope. What you get from us at this stage is a written Discovery report, a prioritised opportunity list, and a proposed scope for the first build.
2. Design
Design turns the Discovery findings into something concrete enough to cost, build, and argue about. For each workflow going into the build, we specify which agent does what, which systems it needs to read from and write to, what the human still owns, and where the boundaries of automated authority sit. If an agent can create a draft but not send it, that's spelled out. If a decision escalates to a person above a value threshold, that's spelled out too.
You see a design document per workflow, showing the end-to-end path, integration points, failure modes, and the exceptions we're not automating. We agree on it before we write a line of production code, and any material change during Build comes back to that document rather than being quietly absorbed. Design is also where we surface the awkward questions early — access, permissions, data ownership, what happens on a bank holiday, who signs off on a change to a live workflow — while they're still cheap to answer.
3. Build
Build is the actual construction: the agents, the integration layer, the orchestration logic that holds the workflow together. We treat this like engineering, not a prompt experiment. Code is version-controlled, changes are reviewed, and every step of the workflow has a defined input, output, and failure behaviour. Nothing runs on trust alone.
We keep the tech-stack conversation light in briefs, deliberately. The value isn't in name-checking whichever framework is fashionable this quarter; it's in delivering something disciplined enough to sit inside your operations without leaking edge cases. Where you already have an internal engineering team, we build in a way they can inherit — clear structure, clean interfaces, notes on the calls we made and why. Where you don't, we build to be readable and inspectable rather than clever, so nothing in the system is dependent on us being the only ones who understand it.
4. Test
Nothing touches live data or a real customer until it's earned it. Testing runs in layers. We start with dry runs against synthetic or historical data, so we can compare the agent's output to a known-good answer. We move to shadow mode, where the workflow runs in parallel with the current process and produces recommendations without executing them. Only then do we begin a staged rollout — a small share of live volume, watched closely, widening as confidence holds.
You see the test plan up front and the results as they come in, including the cases we broke on purpose. If the workflow can't hold up to shadow mode, it doesn't get promoted. We'd rather delay a go-live by a week than hand you a system that quietly does the wrong thing.
5. Deploy
Deployment is the cut-over moment, and we treat it as an event rather than a background upgrade. There's a defined go-live window, a rollback plan, and a named person on both sides who owns the switch. We do a joint check of monitoring, alerting, and the escalation path before we flip anything, and we agree what a "no-go" call looks like — the criteria that would delay the cut-over rather than let it drift live under pressure. Your team knows what "normal" looks like on day one and what to do if it isn't.
Handover is written down, not implied. That means runbooks for the day-to-day operators, an admin guide for whoever will own the workflow inside your business, and a short walkthrough session so nobody meets the system for the first time via an incident. If the workflow needs a specific permission granted or a mailbox re-configured, we'd rather have that agreed in Deploy than negotiated at 8am on day two.
6. Service and Operate
Most consultancies check out here. We don't. Once a workflow is live, it needs the same care as any other production system: monitoring, iteration when the surrounding business changes, and someone on the hook when it misbehaves. We run ongoing service under a clear SLA, with a defined response time, a monthly service review, and a change-log that shows exactly what we've adjusted and why.
Iteration matters because the workflow that ships is never the final version. Volumes shift, upstream systems change, the business finds a use case it didn't have on day one, a vendor changes an API and something silently starts failing at 3am. Having the team that built it stay close to it is the difference between an AI workflow that quietly compounds and one that slowly rots. Service is where the initial build becomes a durable capability, and it's the stage we put the most thought into precisely because most of the industry treats it as an afterthought.
Where to start
If any of this sounds like the shape of a problem you're carrying, the first move is a Discovery conversation. It's low-commitment on your side and gives both of us enough signal to decide whether the fit is right. From there, the six stages above are the same every time — the only thing that changes is which of your workflows we point them at first.