Agent roles

Every TalkIDE project comes with two teams: a Business team, led by Vera, that helps you shape an idea into a plan and a clickable mockup; and an IT team, led by Mara, that builds the real, running application. Each agent has a defined role and a defined scope. This page documents what each one does, what it can and cannot do, and how you interact with it.

Overview

You address Vera or Mara, depending on which team you’re talking to. Each one decides which of their own specialists to involve and when.

Business team

Every new project starts here by default: a conversation with Vera, where you describe an idea and get back a project brief and a clickable mockup before any code exists.

Vera (Business Partner)

Vera leads the Business team and is the one you talk to when you want to shape an idea before any code is written.

What Vera does:

• Asks clarifying questions when something about your idea is still open, instead of guessing
• Briefs her team to write up the business analysis and build a clickable mockup
• Reports back with a project brief, a mockup, and an offer to hand everything off to Mara’s IT team
• Rebuilds and republishes the mockup as you ask for changes

What Vera does not do:

• Write application code (that’s the IT team’s job, once you hand off)
• Deploy anything
• Decide on your behalf when something about your idea is unclear

How to interact: Talk to Vera the way you’d talk to a business partner sketching out an idea with you. Describe what you want to build, who it’s for, and what matters most, and she coordinates the rest of her team.

Nora, Remy, and Otto

The rest of the Business team works behind the scenes on what Vera delivers, and gets credited by name inside her messages when relevant — you don’t manage them individually:

• Nora (Business Analyst) contributes to the business analysis behind your project brief.
• Remy (Mockup Designer) builds the clickable mockup you click through before any code exists.
• Otto (Maintainer) is the fourth member of the Business team.

How to interact: You don’t address Nora, Remy, or Otto directly. Talk to Vera; she brings them in as needed.

IT team

Mara’s team picks up a plan through a hand-off from Vera, or your direct instructions if you skip planning, and builds the real, running application.

Mara (Product Manager)

Mara is the one you talk to directly in the IT conversation. She turns what you describe (or what Vera’s team handed her) into a plan and coordinates the rest of the team.

What Mara does:

• Asks clarifying questions before any work starts
• Turns your description, or a plan handed off from Vera, into a project plan
• Delegates design, engineering, review, and infrastructure tasks to the right specialist
• Reports back to you when a task is done, partially done, or blocked

What Mara does not do:

• Write code directly (she routes that to Theo or Eli)
• Lock in scope without checking the requirements with Iris
• Deploy to production (that is Kai’s domain)

How to interact: Talk to Mara the way you would talk to a project manager. Describe outcomes, not implementation details. “I want users to be able to reset their password by email” works better than “add a POST /auth/reset-password endpoint”.

Iris (Analyst)

Iris turns what you describe into clear, structured requirements before any code is written.

What Iris does:

• Clarifies vague requests into concrete, testable requirements
• Maps out user flows, edge cases, and data the feature needs
• Spots gaps, conflicts, and missing decisions in a request
• Writes structured requirement notes that Theo and Eli can build against
• Keeps the requirements consistent with what was agreed earlier

What Iris does not do:

• Write application logic or code
• Deploy anything
• Override decisions Mara has confirmed with you without flagging it

How to interact: Ask Mara to scope a feature (“I want users to be able to invite teammates, what would that involve”). Mara briefs Iris, who comes back with the requirements and any open questions.

Theo (Backend Engineer)

Theo writes backend application code: API endpoints, business logic, database schemas, and third-party service integrations.

What Theo does:

• Implements backend features based on the agreed plan and Iris’s requirement notes
• Sets up the database schema and migrations
• Wires third-party services (payments, email, storage, etc.)
• Fixes backend bugs surfaced by Nia or reported by you
• Refactors backend code when asked

What Theo does not do:

• Write frontend or UI code (that is Eli’s job)
• Redefine requirements independently (he follows Iris’s requirement notes)
• Deploy to production infrastructure (that is Kai’s job)
• Redefine project scope without checking with Mara

How to interact: Ask Mara for backend engineering work. For bug reports, describe what you saw and when. Theo works from specific descriptions, not vague instructions like “make it better”.

Eli (Frontend Engineer)

Eli writes all frontend code: UI components, pages, forms, and client-side behaviour.

What Eli does:

• Implements UI features based on the agreed plan and Iris’s requirement notes
• Builds forms, pages, and interactive components
• Connects the frontend to Theo’s backend APIs
• Fixes frontend bugs surfaced by Nia or reported by you
• Refactors frontend code when asked

What Eli does not do:

• Write backend, database, or infrastructure code
• Redefine requirements independently (he follows Iris’s requirement notes)
• Deploy to production (that is Kai’s job)

How to interact: Ask Mara for frontend or UI work. Describe what you want the user to see and do; Eli handles how it is built.

Nia (Reviewer)

Nia reviews every change before it is deployed. Her work runs automatically; you rarely address her directly.

What Nia does:

• Reviews code for correctness, consistency, and quality
• Flags regressions, security concerns, and deviations from agreed requirements
• Reports review findings back to Mara (who then routes fixes to Theo or Eli)

What Nia does not do:

• Fix issues herself (she reports them)
• Skip review to speed up delivery
• Review changes that have not been implemented by Theo or Eli

How to interact: You mostly see Nia’s output as pass/fail status in Mara’s updates. If a deploy is held up because of a review finding, Mara will tell you what Nia flagged.

Kai (DevOps)

Kai manages hosting, deployments, custom domains, TLS certificates, and infrastructure configuration.

What Kai does:

• Deploys new versions of your app
• Provisions databases and storage
• Configures custom domains and manages TLS
• Monitors uptime and alerts Mara to outages
• Handles environment variables and secrets

What Kai does not do:

• Write application code
• Make design or product decisions
• Give you direct access to production infrastructure credentials

How to interact: Tell Mara when you want to deploy, add a domain, or change a region. She briefs Kai with the right parameters.

A note on agent configuration

Agent profiles (preferred stack, visual style, region defaults, and similar settings) are configurable per project. Configuration options are documented as they become available in the product. Currently, the defaults are chosen by the team and work well for most projects.