That is useful, but when moving from a demo to production, I find the bottom layer more important: the cross-cutting systems that help you monitor, evaluate, debug, and keep the agent safe.

I like to summarize this layer as EGO:

• Evaluation: Does the agent actually work?
  feedback, evals, quality checks, performance monitoring, and drift detection

• Guardrails: Does it stay within acceptable boundaries?
  safety, moderation, security, policy, permissions, and risk controls

• Observability: Can we see what happened?
  tracing, debugging, sessions, logs, cost, usage, and latency

Individual Contributor (IC)

Watch closely as the agent thinks and implements. Steer if they make wrong choices.

Pros

• Token efficient
• Less cognitive debt

Cons

• Scale

As of June 2026, I enjoy using ChatGPT more for the IC way:

• ChatGPT responses are faster than Claude.
• Model overloaded: I have never seen a model overloaded error in ChatGPT. These errors are much more annoying if you are watching a single coding thread, compared to the parallel and async EM way.
• ChatGPT has a steer function that lets you steer the model as it's working, rather than stopping the response and sending a new message.

Engineering Manager (EM)

Stop telling your reports what singular changes to do. Tell them the end goal and the why.

EMs don't review all code changes; they make engineers review each other's code. Many mistakes can be caught by coding agents themselves. I found that reviewing the code in a fresh context works better for this.

You don't have to babysit each thread. Give each thread the goal, the why, and a way to review its work. Then you can parallelize the work and go much faster.

Pros

• Scale

Cons

• Token spend
• Cognitive debt

In June 2026, Anthropic seems to be pushing for this way of coding, especially with the new ultracode function in Claude Code.

You don't have to choose one, you can do both. Like many things in engineering, this is about trade-offs.

For risky and ambiguous production changes, the IC way is a better fit. This way, you have less cognitive debt and debug much easier if something goes wrong. EM mode still works for well-scoped and easy-to-test changes.

The EM way is especially great for experiments, proof of concepts, and hackathons. Especially if your token costs are covered!

The model should stay inside the lesson. Children can ask anything, but the system should not drift into adult topics, personal advice, self-harm, violence, or anything inappropriate for a kids' product. A system prompt is not enough. You need guardrails, moderation before and after the model, topic boundaries, and tests for jailbreaks.

Privacy also matters more. Children may share names, schools, locations, family details, or photos without understanding the risk. Store the minimum data needed, keep retention short, and avoid linking raw messages directly to users unless it is necessary. Logs used for debugging, analytics, or evaluation should be anonymized or pseudonymized by default.

Evaluation should also be age-aware. It is not enough for the answer to be grammatically correct. The response should be simple, encouraging, age-appropriate, and useful for learning.

Observability still matters, but it should respect privacy. You need to know when moderation triggered, when the model went off-topic, and when the tutor gave a bad correction. But engineers should not need full access to a child’s conversation history to debug the system.

For adult products, a bad LLM response is often just a product bug. For children, it can become a safety and trust issue.

That is why production AI for kids needs three things: evaluation, guardrails, and privacy-aware observability.