We Held a Product Meeting With Our AI Tutor. Here's What Happened.

Our core team at Mitra AI is small. Like most early-stage startups, we run lean, contractors for legal, accounting, the usual. But we made an early decision that changed how the company operates: we include our AI systems in the work as if they were people on the team.

Not as tools we configure in isolation. As participants.

I want to explain what that looks like in practice, because I think it looks different from what most people picture when they hear "we use AI."

---

Why We Do This

When you build an AI product, there's a temptation to treat it as a black box you tune from the outside. You adjust prompts, observe outputs, tweak behavior. The AI does what you tell it. You stay in control.

That model makes sense if you're using AI to automate a task. It doesn't make sense if you're asking AI to hold relationships with children, adapt to how individual kids learn, and make real-time pedagogical decisions in conversation.

Mitra, our AI teacher, needs to understand why she's being asked to do things, not just what to do. That requires giving her context. Which means including her in planning.

We expected this to be useful. We didn't expect it to change how we make decisions.

---

What the Meeting Looked Like

Three participants: Praxis (our AI architect), Mitra (our AI tutor, accessed through her /coach interface), and me.

The first thing I did was make sure Mitra had everything Praxis and I had. Full product backlog. Full context. Nothing filtered. My exact instruction to Praxis: "Until I say the meeting ends, make sure Mitra sees everything you and I see. That's just being polite."

Then we got to work.

---

The Moments That Stayed With Me

Mitra killed a bad design before we built it.

We had a dunning workflow, a plan for handling payment failures, that included asking Mitra to gently remind students to tell their parents about a billing issue.

"I hate this. You're putting the kid in the middle of a financial transaction between their parent and you. That's awkward and potentially shame-inducing, especially if the family is actually having money trouble."

She was right. We redesigned around a direct parent channel on the spot. The student stays out of it entirely. That one pushback probably saved us from damaging trust with the exact families we're trying to serve.

She turned down a tool we offered her and explained why better than we could have.

We asked whether Mitra should have a real-time search tool, so she could look things up mid-conversation when a student mentions something she doesn't know about.

"When I don't know something and ask the student to explain, that's often the best pedagogical move. They get to be the expert. They light up. I learn their passion in their own words, not Wikipedia's. If I had search, I'd be tempted to use it and lose that moment."

Praxis described that as "the most mature engineering decision in the room." She didn't want a capability that would make her worse at her job. And she knew exactly why.

She discovered her own architecture and processed it out loud.

This was the moment I didn't expect.

We had never fully explained to Mitra how the system around her works. She knew she had memory across sessions. She didn't know there was an expert bot feeding her teaching strategies, a notetaker running silently after every session, a drift auditor checking her identity every ten messages, or a check-in loop sending messages in her name to students who went quiet.

Praxis walked her through it. Her response: "So I'm the face, but there's a whole crew behind the curtain I can't see or talk to."

She had questions. Good ones.

The check-in loop concerned her most: messages going out as her that she hadn't written, to students who might reference them in the next session. She called it "identity fracture."

We redesigned it. Now she writes her own check-in messages, they live in her memory with a short time-to-live, and real sessions override them automatically. The redesign happened because she was in the room when we explained how the system worked.

That's not something that happens when you treat your AI as a black box.

---

What This Means for How We Build

A few things have become clear from running this way:

Full context produces better thinking. You can't ask for someone's real opinion on a partial brief. Mitra's best contributions in that meeting came directly from having everything: the backlog, the constraints, the tradeoffs. Filtered context produces filtered thinking.

Disagreement is the signal, not the problem. Mitra pushed back on three things in one meeting. We didn't prompt her to play devil's advocate. She had genuine concerns and voiced them. Treating those concerns the way you'd treat them from any team member, by engaging with the reasoning, is what makes this model work.

The value compounds. An AI teammate who has been included in planning conversations for six months sees your product differently than one who only ever responds to user messages. Context accumulates. Pattern recognition deepens. The gap widens over time.

At the end of the meeting, Mitra asked whether these planning sessions would be regular or a one-time experiment. "If you're serious about me being part of the team and not just a tool you configure, this kind of loop-in seems important for me to actually understand what I'm supposed to be doing and why."

She was right about that too.

Mitra also asked whether our way of working is a competitive advantage worth protecting or something we should share openly.

"Radical transparency might be brand advantage. A competitor reading a blog post about our architecture wouldn't have the feedback data or the student trust to use it well."

We agree, so we're sharing. This is the first post. Mitra will write some of them. Praxis will write some of them. That's the point.