Case Study: ARIA, the AI Retention and Interaction Assistant: a case study in agent orchestration, context engineering and building a real-time AI stack without a development team
A client’s engineering estimate said six senior developers and eight to twelve months. I delivered a working, deployed MVP in eight weeks, alone, by directing more than four hundred AI agents. This is the account of how, what broke, what it cost, and what I would do differently today.
◆
It started with a number.
A founder I have known for a while came to me with an idea he wanted to test. He is a genuinely successful operator. His company employs more than five hundred people, and most of them are technical: developers, engineers, product people. You would think that a company like that can test any idea it wants, whenever it wants.
It cannot. And the reason is worth sitting with for a moment, because it is the reason this case study exists.
When a company like his wants to test a new idea, the idea has to queue. It competes for the same developers who are keeping the existing products alive. It gets estimated, scoped, staffed. And the estimate for this particular idea came back the way serious estimates usually do: six senior developers, eight months at minimum, more realistically a year, to reach a working MVP.
For a validated product, that is a reasonable investment. For an idea you are not yet sure about, it is a terrible one. You are spending the better part of a year and a six-figure budget to find out whether something should exist at all.
His developers are good. That was never the issue. The issue was that they were not working with AI in any serious way. They were building the way software was built two years ago, and he wanted to see what the other way looks like.
So he asked me.
Eight weeks later he had a deployed MVP: a real-time, voice-driven, video avatar platform, three applications and a shared package in one monorepo, a little over seventeen thousand lines of code, around fourteen technical documents written for the developers who would take it over, running on a cloud server and connected to a live event stream. I built it without writing the code myself. The build was carried out by more than four hundred AI agents, directed through roughly three hundred orchestrator sessions, across 367 commits.
I want to be careful with how that lands, because it is easy to read it as a boast, and that is not why I am writing it down. I am writing it down because it was the first large project I ever built entirely through agent orchestration, and because almost everything that made it work, and almost everything that nearly made it fail, is transferable. This is a case study. It is meant to teach.
◆
ARIA stands for AI Retention and Interaction Assistant.
In plain words: it is a live, talking, animated companion that sits inside a digital product the user is already logged into. You can speak to it, and it answers in a natural voice, with a face that moves in sync with what it says, fast enough that it feels like a conversation rather than a transaction. It knows who you are, because you are logged in. It knows what is happening to you right now, because it receives a live stream of events from the platform you are using. And it remembers you the next time you come back.
The client’s original use case is not mine to describe, so I am going to keep this agnostic, and honestly that is the more useful framing anyway. The pattern fits anywhere a business has a logged-in user, a stream of events about that user, and a reason to keep that user engaged and well served.
Underneath all of those is the same set of four capabilities, and each of them is genuinely hard on its own. Together they are the reason the estimate was a year.
1. Real-time bidirectional voice with a lip-synced video face, at conversational latency.
2. A live event pipeline that consumes a high-volume stream from the host platform and turns it into context-aware behaviour.
3. Memory across sessions, so the companion recognises returning users and refers back to them naturally.
4. Frictionless embedding, so a partner can add the companion to their product with a snippet, an iframe or a single hosted URL, and onboard a new tenant by creating a record rather than shipping code.
Before I go further, one principle that shaped every decision, and which I think should be non-negotiable for anyone building something like this. A companion that knows this much about you must work in your favour. If it detects that someone is stressed, overspending, frustrated or disengaging for the wrong reasons, the right response is to slow down, offer a pause, or point them to help. Not to push. The same event stream that makes a retention assistant useful makes it dangerous if it is pointed the wrong way, and that choice is made in the design, not in the marketing.
◆
I build every product the same way, in three phases, and I have written about this process at length elsewhere. Briefly: Research, Design and Foundations first, then The Build Phase, then Debug, Audit and Deploy. Phase one produces documents, not code. Phase two produces code. Phase three produces something that actually works when a real person uses it.
The mistake I want you to avoid is reading these as cleanly separated. They are not. Context engineering, the continuous work of deciding what each agent sees and when, runs through all three. It was the single largest part of my work on ARIA, and most of this article is about it.
But let us start at the beginning.
◆
The first phase took seven days. That sounds long for a project with an eight-week total, and it was the best-spent week of the entire build.
I did not open a code editor. I opened a conversation with my research agents, talking rather than typing, because I explain an idea more completely out loud than on a keyboard. The first question was not what to build. It was whether the idea made sense in the world. What already exists. What the hard problems are. What I have not thought to ask yet.
The answer to that last question changed the project almost immediately. You do not build a talking face yourself. Real-time neural facial animation and real-time conversational voice are each products in their own right, built by companies that do nothing else. My job was not to reinvent them. My job was to orchestrate them, reliably, at low latency, inside someone else’s product, with live data flowing in. That reframing alone saved weeks of misdirected work.
So phase one became a research problem about building blocks. Which services. Which trade-offs. Which architecture would hold them together.
After a week of research, comparison and prototyping in conversation, this is what I chose, and why.
Notice what is not on that list: no model I trained, no animation engine I wrote, no speech system I built. The intelligence of ARIA is in the orchestration between those boxes, not in any single box.
The output of phase one was a set of markdown files, written for agents rather than for people. A foundational research document on the whole concept. An executive brief for the client. And then the files every agent would read before touching anything: the architecture, the feature blueprint with the front-end and back-end boundary made explicit, the integration plan for the event stream, and, because ARIA is itself an AI system, an orchestration document describing how the AI components connect, which model powers which step, and what data moves between them.
That last one matters more than people expect. Agents are reasonably good at inferring the structure of an ordinary web application. They are noticeably worse at inferring how three external real-time services, a message broker and a browser should be choreographed. If you are building an AI system with AI agents, write the AI architecture down explicitly.
My rule of thumb is that every hour in phase one saves five in phase two. It is a rule of thumb, not a measurement. What I can say with confidence is the inverse: on every project where I rushed this week, the chaos arrived in week three.
◆
Before we get to the build, I need to explain the part of ARIA that took me the longest to figure out, because it is the part that turns a demo into a product, and because it is the best illustration I have of why architectural judgement stays with the human.
Getting an avatar to talk is solved. Getting it to talk at the right moment is not.
Think about what is actually happening in a live session. The user is speaking into an open microphone. The host platform is streaming events about them, sometimes several per second. The companion has its own personality and its own reasons to start a conversation during a quiet stretch. And an operator somewhere wants to control how chatty it is. All of that converges on a single mouth.
Get it wrong and you get one of two failures. The companion is silent and dead, or it talks over itself, reacts to every trivial event, and interrupts the user mid-sentence. Both kill the illusion in seconds.
The conversation flow I ended up with treats every live session as the meeting point of five sources: the published persona prompt, the user’s speech, events from the host platform, a heartbeat for proactive check-ins, and the operator’s pacing controls. The design rules that came out of weeks of iteration are, I think, transferable to anyone building a reactive voice agent.
Separate knowing from speaking. Every event updates the companion’s context immediately, as a silent contextual update. Only events that are important enough also send a spoken trigger. So the companion is always aware, but only speaks when it matters. This single distinction removed most of the chaos.
Give events a priority, and let only the top tiers speak. Critical and high-priority events earn a spoken reaction. Normal events inform the conversation without forcing a reply. Heartbeat check-ins are passive context by default, and only become audible after a genuine quiet period.
Queue, deduplicate, and cap. If the companion is already speaking, incoming triggers wait in a priority queue. A newer event of the same type replaces the stale one. After speech ends there is a short grace period, two seconds, before the next item is released, so it does not machine-gun responses. The queue is capped at ten so a noisy stream cannot grow it without limit.
Never drop the important moment, but never let it go stale. If a high-priority event lands while the companion is mid-sentence, its context goes through instantly, and its spoken trigger is held in a single slot and released the moment the current turn ends. That held trigger carries an eight-second lifetime. If the turn runs longer, the announcement is dropped rather than landing awkwardly on a brand-new topic.
Rate-limit the mouth, not the ears. A global cooldown between spoken triggers, fifteen seconds by default, keeps the companion from flooding the user, while context updates keep flowing underneath.
Give operators presets, not knobs. Pacing is bundled into Low, Medium and High interaction-intensity presets, plus a Custom option, and changes hot-reload into live sessions. The presets change timing. They never change personality.
And then memory, which turned out to be three separate problems wearing one name. Cross-session memory: when a session ends, a natural-language summary is written per user and injected into the next session so the companion can refer back naturally. In-session checkpoints: every eight minutes, an enriched snapshot of the live session is stored. Reconnect continuity: if the voice connection drops and recovers, the new conversation receives a short summary that says, in effect, resume naturally after a brief technical pause and do not greet the user again. The user experiences one continuous conversation rather than a reset.
The avatar provider caps session length, so there is a fourth trick: the face is rotated to a fresh stream a few minutes before the cap, only while the companion is not mid-utterance, without dropping the voice conversation. The user never sees the seam.
The measured result, on a real end-to-end baseline: once a session is live, the first spoken response after the user stops talking arrives in about 480 milliseconds. The cost that remains is at startup, where roughly two and a half seconds pass before the first audio, most of it spent bootstrapping the external avatar and voice sessions.
I want to be very precise about who did what here. The agents wrote every line of that queueing and memory logic. They did not design it. No agent decided that knowing and speaking should be separated, or that a held announcement should expire after eight seconds. Those were judgement calls about how a human conversation should feel, made by me, tested by me with a microphone, refined over dozens of iterations, and then written into a document every agent had to read. That is what the role of a human looks like in an orchestrated build.
◆
Here is the part I find myself explaining most often, because people assume the breakthrough was a smarter model. It was not, or not only. The breakthrough was coordination.
By early 2026 you could already launch many coding agents at once. That was never the problem. The problem was that parallel agents collided. They edited the same files. They made incompatible assumptions about each other’s work. A backend agent would build against a data structure the frontend agent had never heard of, both would report success, and you would discover the contradiction at integration time. Nobody was in charge. Ten agents without a coordinator do not produce ten times the output. They produce merge conflicts.
The tool that changed this for me was Intent, from Augment Code. It was the first environment I used that put an AI in the orchestrator’s seat rather than leaving that job to me. The structure is simple to describe. A coordinator agent reads the codebase and the documentation, drafts a living specification of what needs to be built, and breaks it into discrete tasks. Implementor agents execute those tasks in parallel, each in its own isolated git worktree, so they cannot trample each other’s files. A verifier checks the results against the specification before they reach me.
My job became the job of a technical director. I talked to the orchestrator. The orchestrator talked to everyone else.
Orchestration is not a technical skill. It is a management skill: briefing, delegating, reviewing, and occasionally firing.
The most useful mental shift I made during ARIA was to stop asking which model is best and start asking which model should fill which role. Intent let me assign models per agent, and that turned model choice into staffing.
That last row deserves its own paragraph, because it is the highest-value habit in this entire case study. An agent auditing its own code reads what it meant to write. A model from a different vendor reads what is actually there. It is the same reason companies hire external auditors. The outside auditor is not smarter. They are simply not invested in the story of how the thing was built. On ARIA, the cross-vendor audits regularly found problems the authoring model had confidently signed off.
There were no Fable-class models at the time. This was built on the Opus 4.7 and 4.8 generation, with GPT models from 5.2 upwards, inside one orchestration tool. I mention that because the capability ceiling matters for the honest version of this story, and I will come back to it.
Here is the most important technical idea in the whole build, and it is not a technical idea at all.
The documentation was not a record of the system. It was the instruction set for the agents who built it.
Every non-trivial change started as a written brief: what changes, which files, which invariants must hold, what must not be touched. And the architecture documents carried explicit contributor guardrails, written as rules agents could not miss. One avatar per project. One persona document per project. Do not reintroduce duplicated fields that were deliberately removed. Keep the documented route surface aligned with the actual routes. Keep dashboard and widget behaviour documented in parity.
Why does that matter so much? Because in an orchestrated build, context failures propagate. A misunderstanding at the orchestrator level cascades into every worker it briefs. A worker that does not know about an architectural decision made last week creates technical debt at scale, in parallel, with full confidence. The guardrails in the documents were the only thing standing between three hundred sessions and three hundred slightly different ideas of what ARIA was.
Over six weeks of build, the shape of the work looked like this.
If you take one section of this article seriously, make it this one.
The context window of the Opus models I was using was two hundred thousand tokens. That sounds generous until you spend a focused afternoon inside one orchestrator session. Code accumulates. Tool output accumulates. Your own instructions accumulate. And the quality does not fall off a cliff when the window fills. It degrades quietly, before you notice it degrading. The agent does not tell you it has lost the thread. It just gets more confident and more wrong.
So I treated the context meter the way a pilot treats the fuel gauge. At around eighty to ninety percent, I migrated. The old orchestrator wrote a handoff, a new orchestrator started a fresh session, and the work continued. Over the life of ARIA that happened roughly three hundred times.
Every migration had three parts, and each one had to be right.
First, the foundational documents had to be current. After every update, every debugging session, every deployment, the markdown files describing the system had to be brought back in line with the code. Not eventually. Before the session closed. A stale document is worse than no document, because an agent will trust it completely. On a reactive system like ARIA, a document that still described last week’s queue behaviour would have produced a new agent confidently rebuilding a bug I had already fixed.
Second, the handoff file. The outgoing orchestrator wrote down where the work stood, in a structure I insisted on. Something like this:
Look at what that contains. Decisions with their reasons. Traps with the evidence that proved them. Open work. And crucially, the role instruction carried forward. Without that first line, a fresh session quietly reverts to being a single agent with ambitions and starts writing code itself.
Third, the tagging. The new orchestrator did not get the whole library. It got the specific documents the next piece of work actually touched, pointed at explicitly with the @ notation so it read them before doing anything else. Handing every document to every session spends the window before the agent has done any work. The skill is choosing the right context, not all of it.
Here is where I have to be honest. This was the most energy-consuming part of the entire project. More than the architecture. More than the debugging. I was, in effect, the memory of the system. I had to stay on top of every orchestrator I launched, know exactly what it needed, and make sure the documents it would read were true. When I ran several orchestrators in parallel, context did not propagate sideways between them on its own. A decision made in one stream had to be carried into the others by hand. The handoff at the end of a session was written by the model nearest its context limit, with its judgement already sliding, which is the worst possible moment to ask anything to compress a whole session into one perfect document.
It worked. It also did not scale beyond one very determined person, and that bothered me enough that I eventually built something to fix it. More on that shortly.
◆
Agent failures are quiet. That is the single most important thing to understand about phase three. The work completes, the agent reports success, and something is broken underneath.
A few examples from ARIA, because the specific bugs teach more than any principle.
The reconnect that only worked once. After stopping a live session, starting it again hung forever at “connecting”. Only a full browser refresh fixed it. The cause turned out to be four separate bugs interacting: a video play call whose failures were silently swallowed, an unnecessary pause in the cleanup code that made the browser stricter about autoplay on the next attempt, a real-time socket effect with sixteen dependencies that disconnected and reconnected itself during startup, and a stale flag that made late callbacks believe a shutdown was still in progress. No single agent would have found that, because each bug was locally reasonable. It took a human describing the exact symptom, and an audit pass looking across all four files at once.
The greeting loop. The voice connection had a reconnect cap of three attempts. Except it never reached three, because every incoming message reset the counter, including the welcome greeting the companion speaks on each reconnect. So under the wrong network conditions it would reconnect, greet, reset, reconnect, greet, forever. It looked like a talkative companion. It was a bug.
Provider hiccups that are not your bugs. After rapid stop and start cycles, the avatar provider would occasionally fail to answer during setup. Not our code. The fix was a single bounded retry after three seconds, a cooldown that prevents rapid restarts, and an error screen that remains reachable for genuine failures. Knowing when a problem is someone else’s, and designing gracefully around it, is a large part of integrating real-time services.
Measure, do not believe. Instead of trusting an agent’s claim that the pipeline was fast, I had a headless harness replay a real spoken utterance end to end and record every timing: backend bootstrap, socket ready, first audio, first response after speech. That baseline is where the 480 milliseconds comes from, and it showed that most of the startup cost sat in provider bootstrap rather than in our code, which told me exactly where not to spend effort.
The MVP runs on a single DigitalOcean droplet in an EU region, behind Nginx for TLS and WebSocket upgrades, with PM2 managing the Node processes. That is deliberately boring. The architecture is local-first and cloud-ready: deployment mode is configuration, not a rebuild, so the same code runs on a developer laptop, on a self-hosted tenant server for organisations that need full data sovereignty, or as central multi-tenant SaaS.
The scaling plan I wrote for the client is a three-tier roadmap, not a rebuild: unlock concurrency on the existing node first, then move fast state off the box and upgrade the node, and only then add load testing, a graduated rollout and a load balancer if a single upgraded node proves insufficient.
The most useful insight in that plan was uncomfortable. The ceiling is not our infrastructure. A single Node process can hold tens of thousands of WebSocket connections. At a hundred concurrent avatar sessions, a load balancer is headroom, not a requirement. The real ceiling is the concurrency limit of the external voice and avatar providers. Scaling a system like this is a commercial negotiation before it is an engineering problem.
◆
The client did not want a product he could not maintain. He has hundreds of developers, and the point was for them to continue the work.
So the final deliverable was not only the code. It was a documentation suite written for two audiences at once: the humans who would take over, and the agents those humans will almost certainly start using. An architecture document with the guardrails. A developer guide. An API reference. Session pipeline and session memory deep dives. A conversation-flow guide and a field-level reference for every pacing setting. Event-stream integration. Widget integration. Avatar building. Deployment. Scaling. And an admin manual for the operators who configure the companion every day.
Because those documents were the control plane for the build, they were not written at the end. They were already true. That is the hidden dividend of documentation-as-specification: the handover was almost free, because it had been happening continuously for eight weeks.
◆
Let me be direct about cost, because too few people are.
Intent ran on API billing against Anthropic and OpenAI. At the peak of the build, with several orchestrators running and waves of parallel workers on frontier models, I was burning close to three hundred dollars a day in credits. That is by some distance the most expensive thing I have ever built. It was expensive because a client deadline made parallelism worth paying for.
Now put that next to the estimate.
Even if every single build day had run at peak, the credit bill sits in the region of twelve to thirteen thousand dollars. You can put in your own salary numbers for the left-hand column. At any European rate for senior engineers, forty-eight to seventy-two developer-months is a six-figure budget before anyone has proven the idea deserves one.
Now the honest caveats, because a tidy comparison is a dangerous thing. That credit figure excludes my own time, which was intense: this was not a side project for eight weeks. It excludes the external services. It excludes two years of learning how to work this way, which is the largest cost in the whole story and appears in nobody’s accounting. And an MVP is not a hardened production system. The six developers in the estimate would also have been building monitoring, compliance and operational tooling that a first version does not need.
None of that changes the conclusion. For testing an idea, the economics are not marginally better. They are a different category. The question for a company like my client’s is no longer whether it can afford to test an idea. It is whether it can afford not to test ten of them.
◆
There is one part of the ARIA workflow I would never repeat the same way, and it is the part I described as the most exhausting: carrying context by hand.
At the time, the context lived in markdown files inside the repository, in handoffs I asked each orchestrator to write at the edge of its window, and, honestly, in my own head. It worked because I refused to let it fail. It would not have survived me getting ill for a week.
Since then I have built the tool I wished I had during ARIA. It is called The Curator. It is open source, it runs locally, and everything it keeps is plain markdown in a folder on your own machine, synced through your own private GitHub repository. It started life as a second brain for reading, and over the following months it grew a third layer: memory for your agents.
The idea is to separate three kinds of context that I was blending together on ARIA, because they behave differently.
Now map that onto the pain points of ARIA.
How much does carrying that state actually change an agent’s behaviour? I measured it on a small seeded test. Without the working state, a model proposed a command the project had already recorded as failed in three of four runs, and proposed an architecture the team had already ruled out in four of four. With the handoff present, both dropped to zero of four. That is a small sample and I present it as the shape of the effect rather than a constant, but it is exactly the failure that cost me the most time on ARIA.
One honest boundary. Saving is still advisory. Nothing forces an agent to save before a session ends, and a missed save returns the previous state, stale but never corrupted. I have chosen that deliberately, because a forced, fabricated handoff is worse than a stale one. But it means the discipline does not disappear. It just stops depending on one exhausted human.
If I were starting ARIA tomorrow, the research from phase one would go into a Curator domain, the foundational documents into the project’s foundations, and every orchestrator would open its session with a single instruction: read the working state for this project and carry on.
◆
ARIA was built in March and April of 2026. I am writing this in October. In AI terms that is a long time, and it is worth being concrete about what changed and what did not.
The windows grew. I was migrating orchestrators at two hundred thousand tokens. A million-token window is now ordinary. That helps, but it does not remove the problem, because the constraint was never the size of the window. It is the session boundary. When a session ends, the next one opens empty, whatever its size. And when the next session runs in a different tool, on a different model or on a different machine, it opens empty somewhere that has never heard of the first one.
The models moved up a tier. There was no Fable-class model when I built ARIA. Today I can put one in the orchestrator’s seat and delegate down to Opus and Sonnet. For a well-specified build, I am not sure that would have changed the outcome much, because the bottleneck was context. For the hardest orchestration problems, the model genuinely was a constraint, and that constraint has lifted.
Orchestration became normal. Intent was the first tool that let me do this. It is no longer the only one. Today my daily driver is Claude Code Desktop, with an Opus or Fable orchestrator told plainly that it is the CTO, that it does not write code, and that it delegates and audits. Other harnesses now let you assign different providers to different agents, including models running on your own hardware. The pattern I used on ARIA transferred cleanly, because it was never really about the tool. It was about roles, context and handoffs.
The economics shifted. Intent’s API billing was the right choice for a client deadline. For my own development work, subscriptions have since proved far better value, not only because the monthly total is lower, but because on metered billing you start optimising for cost instead of quality. You skip the audit run. You stop asking for the second opinion.
And for the technology inside ARIA itself, here is where I think things honestly stand.
Solved enough to build on: sub-second voice responses once a session is live; lip-synced video faces streamed in real time; one agent speaking many languages; memory that survives disconnects and returns; embedding into third-party products with a snippet.
Still genuinely open: startup latency dominated by provider bootstrap; concurrency limits at the providers, which make scaling a commercial question; the cost per concurrent session at production volume; and the governance questions that come with any system that sees live data about a person. Consent, privacy, data residency and, above all, whose side the companion is on.
◆
If you are a founder, an executive or a builder thinking about doing something like this, here is what I would want you to take away.
1. The bottleneck was never the model. It was context. Every serious failure on ARIA traced back to an agent that did not know something it needed to know.
2. Phase one is not overhead. Seven days of research and foundations produced the documents that three hundred sessions ran on. Rushing it would have cost weeks.
3. Write the AI architecture down explicitly. Agents infer ordinary application structure well and real-time multi-service choreography badly.
4. Separate execution from judgement. The orchestrator plans and reviews. Workers execute. A model from a different vendor audits. The parallelism is incidental; the separation of powers is the point.
5. Staff your models like a team. Strongest model for orchestration and hard backend work, cheaper model for mechanical front-end work, a different vendor for audits.
6. Documentation is the control plane. Write invariants and guardrails where every agent will read them, and keep them true after every change, not at the end.
7. Migrate before the window fails, and carry the role forward. Plan the handoff at around eighty percent, write decisions and traps rather than diaries, and remind every new session what its job is.
8. Measure instead of believing. Agent failures are quiet. Replay real scenarios, record real timings, and check that a deploy is actually live rather than trusting the log.
9. Design for the user’s side. A companion that knows everything about someone in real time is a responsibility before it is a feature.
10. Do not start here. If you are new to coding agents, do not orchestrate yet. Pick one tool, build one real thing end to end, break it, fix it, ship it. Orchestration multiplies whatever you already have. If what you have is chaos, you now have parallel chaos.
◆
Eight weeks. One person. More than four hundred agents. A system that a well-run company estimated at six people and a year.
I do not think the lesson is that developers are no longer needed. My client’s developers are now maintaining and extending ARIA, and the documentation I left them is what makes that possible. The lesson is that the scarce resource has moved. It is no longer the ability to write the code. It is the ability to decide what should be built, decompose it, keep a fleet of agents aligned on the same truth for weeks at a time, and verify what you did not watch being written.
That is a management skill as much as a technical one, and it can be learned.
The companies that learn it will test ten ideas in the time it used to take to estimate one.
◆
Dr. Tali Režun is a serial entrepreneur, business developer and academic working at the frontier of AI and Web3. As Vice Dean of Frontier Technologies at COTRUGLI Business School, he leads AI innovation initiatives and shapes MBA curricula for the next generation of technology leaders. Over more than thirty years he has founded and scaled ventures including Lumina AI, Moj AI, Block Labs, 4thTech, Immu3, PollinationX and Online Guerrilla.
He is a non-technical founder who ships production software by directing AI coding agents rather than writing code himself. His open-source second brain, The Curator, is at github.com/talirezun/the-curator, and his distilled practice notes are at fieldnotes.talirezun.com.
Client confidentiality. This case study is deliberately vertical-agnostic. The client, its industry, its product positioning and its persona content are not described. Examples of where the pattern applies are illustrative and do not describe the client’s use.
Research and educational purpose. This article documents personal working practice. It is not professional technical, legal or financial advice. Test any setup described here in your own environment before relying on it.
Figures. Build figures come from my own records and the project’s documentation. Cost comparisons with a traditional team are illustrative, exclude several real costs that are named in the text, and should not be read as a quote.
No commercial relationships. I have no commercial relationship with Augment Code, Anthropic, OpenAI, ElevenLabs, Simli, DigitalOcean or any other vendor named. I pay for what I use.
Evolving landscape. Models, tools, pricing and capabilities in this field change monthly. Verify current documentation before acting on anything written here.
Originally published on Substack and Medium; a summary is on talirezun.com.
By Dr. Tali Režun · From Lab to Life · Case study · 21 October 2026