How the AI team works

TalkIDE is organized around a team of named agents rather than a single chatbot. This page explains the reasoning behind that choice, how the agents coordinate, and what the model means in practice for your projects.

Why a team, not one model?

A single large language model can write code, draft designs, and reason about infrastructure. But it has to do all of those things in the same context window, at the same time, to the same standard. For short tasks that is fine. For a project that grows over weeks, with dozens of decisions layered on top of each other, it degrades quickly.

Role-bound agents address this in a few ways:

• Each specialist loads only the context relevant to its domain, so it can be deeper and more accurate in that area
• Responsibility is visible: you can see which agent did what and why, which makes it easier to identify problems and ask for corrections
• The orchestrator (Mara) can route a task to the most appropriate model for it, rather than using the same heavyweight model for every sub-task
• The team metaphor maps to how most people already think about building a product, which makes the product easier to use

This is a deliberate trade-off. The setup is more complex than a single chatbot. It is slower for trivial requests. But for projects that need to stay coherent over time, the structure pays off.

How orchestration works

Mara is the orchestrator for every project. When you send a message, Mara:

1. Classifies the request (is this a design question, a code change, an infrastructure task, or a clarification?)
2. Decides which specialists to involve, and in what order
3. Hands each specialist a brief with the relevant context
4. Waits for their outputs, checks for conflicts, and assembles a response

From your perspective, you mostly see Mara's replies. The specialist work happens in parallel or in sequence, depending on the task.

View modes

The workspace has two view modes. "Simple" shows Chat and Preview only. "Under the hood" also exposes the code editor, database browser, and lower-level build output. It is a display toggle for how much detail you see, not a separate feature.

Role boundaries and handoffs

Agents do not overlap by accident. The boundaries are enforced by the system, not just by instruction. Iris cannot deploy; Kai cannot redesign a screen. This makes it easier to reason about what changed and why, and it limits the blast radius when something goes wrong.

Handoffs between agents are explicit. When Iris finishes a design pass, she produces structured handoff notes for Theo rather than a free-form description. When Nia finds a failure, she files a structured report that Theo can act on directly.

What the model does not do

The team metaphor is useful, but it has limits worth naming:

• The agents are not human. Mara does not get tired or bored. Theo does not take shortcuts out of laziness. But they do make mistakes, and when they do, you correct them the same way you would correct anyone: by describing what went wrong and what you want instead.
• The team does not make decisions behind your back. Every choice that matters is surfaced to you before it is acted on.

If the team gets stuck on something that requires human judgment at the infrastructure or security level, that is what Concierge is for.