TalkIDE users talk to two teams: a Business team led by Vera, and an IT team led by Mara. From the outside they feel like different products. Vera’s team stays in the world of ideas, requirements and a clickable mockup. Mara’s team writes the actual application. Under the hood, though, they are not two systems bolted together. They run on one shared agent-execution engine, and the split between them is a design decision, not a technical seam.
This post is about that decision: what actually distinguishes the two teams, how a project moves from one to the other, and where we chose to keep things simple instead of building something more elaborate than the problem needed.
Two teams, one engine
Each team is a persona configuration: an orchestrator prompt plus a roster of specialist personas. Vera orchestrates the Business team and stays deliberately tech-agnostic. She never touches code. Her team’s job ends at requirements and a mockup you can click through. Mara orchestrates the IT team, and her specialists are the ones who write, review and ship the actual application.
Both orchestrators run on the same underlying agent-execution engine. There is no separate infrastructure for “planning mode” versus “building mode”. The difference between Vera and Mara is entirely in which prompt and which roster of personas gets loaded, not in which system is running.
That single-engine choice is what keeps the two teams consistent for you as a user. The chat experience, the streaming of responses, all of it works identically whether you are talking to Vera or to Mara, because it is the same infrastructure either way.
Team choice lives in the conversation, not the project
The detail that makes this work cleanly is where the team choice actually lives. It is a property of the conversation, not the project.
A TalkIDE project can have a Business conversation and an IT conversation side by side. Switching teams means switching to a different conversation thread, one with Mara’s orchestrator loaded instead of Vera’s. It never means two orchestrators sharing one live thread.
This matters more than it sounds like it should. Because the team distinction sits at the conversation level, both teams reuse identical chat and streaming infrastructure with zero duplication, while their execution contexts stay fully isolated from each other. Nobody had to build a second chat system for Vera, and nobody had to teach one orchestrator to defer to another mid-thread.
The hand-off: an explicit action, not an AI decision
Moving from planning to building is not something the AI decides on your behalf. You click a hand-off button. That is the trigger, every time.
When you do, Vera’s orchestrator emits a small structured payload: a short summary plus a distilled brief. Not a full transcript dump of your conversation with her, a brief.
Before that hand-off happens, the Business team’s output, the structured docs plus the mockup source, gets committed to the project’s version history. That ordering matters. It means Mara’s team reads from durable, versioned artifacts, not from ephemeral chat memory that could be summarized differently depending on when you look at it. Mara’s orchestrator is then prompted to treat that brief as an already-negotiated starting point, rather than re-deriving the requirements from scratch as if the conversation with Vera never happened.
If you go back to Vera later and hand off again, that second hand-off only carries the delta: what changed since the last one. Not the whole document set repeated.
Building is a different shape of work than talking
The conversational side of TalkIDE, the actual back-and-forth with Vera or Mara, is I/O-bound. It holds session state and needs to survive long sessions as you go back and forth on an idea. That fits a persistent, long-lived process well: one worker per tenant environment, staying up for as long as your session needs it.
Builds and test runs are a completely different shape of work. They are short-lived, they are CPU-bound, and they are naturally parallelizable, since one build doesn’t need to know anything about another. So builds and test runs get dispatched as ephemeral Kubernetes Jobs instead of running inside that same long-lived worker. Each build gets its own throwaway pod, spun up for the duration of that one job and torn down after.
What we deliberately did not build
The more interesting part of this story is the option we didn’t take. We could have invented a new distributed protocol to decouple build execution from the conversational worker: some custom queueing layer, a bespoke scheduler, a purpose-built way to hand work off between processes.
Instead, we paired the shape of each workload to the shape of infrastructure that already exists for exactly that shape. Long-lived, stateful, I/O-bound conversation stays on dedicated persistent pods. Bursty, parallel, CPU-bound build work goes straight to the Kubernetes scheduler, which already knows how to run many short jobs concurrently without one of them starving the others.
Using one infrastructure model for both would have meant either making the conversational worker do double duty as a build runner, which risks one heavy build slowing down everyone else’s live session, or building a custom scheduler to replicate what Kubernetes already does well. Neither was worth it. Matching workload shape to infrastructure shape, and letting the cluster scheduler do the part it’s already good at, turned out to be the simpler and more robust answer.
Why this is worth writing about
None of the individual pieces here are exotic on their own. Persona-driven orchestrators, conversation-scoped state, ephemeral job dispatch: each of these exists elsewhere. What’s worth calling out is how they compose. Two teams that feel like separate products to the user, an explicit and structured hand-off between them, and a build pipeline that borrows the scheduler instead of reinventing it. Together, that’s what lets Vera and Mara feel like two distinct collaborators while sharing one engine underneath.
Curious what building with the team looks like from the other side? Start a project at talkide.app.