When I first wrote about building an AI-powered engineering team with CrewAI, I was focused on the promise of role-based agents. A lead engineer could plan, backend and frontend agents could implement, QA could review, and documentation could follow the work.
That basic idea still holds. Clear specialization helps. What I understand better now is that assigning roles is the easy part.
An AI crew does not fail because it lacks job titles. It fails when context is incomplete, handoffs are vague, and nobody is accountable for the integrated result.
Role prompts are not architecture
Giving an agent a title can focus its attention, but a title does not define the system. “You are a senior backend engineer” may improve tone and priorities. It does not tell the agent which service owns an entity, what compatibility must be preserved, or how failure should be handled.
The useful context is concrete: repository structure, accepted patterns, product constraints, decision records, interface contracts, test commands, and a definition of done. The better I made that context, the less I needed elaborate personas.
I still use roles, but I treat them as lenses rather than substitutes for specification.
Handoffs are where quality disappears
Parallel agents can move quickly when their tasks are independent. Problems begin when one agent makes an assumption that another agent never sees.
A backend agent changes a response shape. The frontend agent codes against the earlier version. A documentation agent describes the plan instead of the implementation. A reviewer evaluates one file without understanding the database migration that made it necessary.
Human teams have the same problem. They solve it through shared artifacts and communication. AI teams need even more explicit handoffs because an agent will often continue confidently with partial context.
I now require outputs that another role can consume: versioned contracts, changed-file lists, decisions and assumptions, commands used for verification, and unresolved risks. “Done” is not a paragraph saying the task went well.
Parallelism has a coordination cost
More agents do not automatically mean faster delivery. If five tasks modify the same foundation, the integration cost can exceed the time saved. Parallel work is most effective when boundaries are clear and outputs can be combined without negotiation.
Research, test design, documentation review, and isolated components often parallelize well. A database schema and every feature depending on it usually do not. I plan agent work the same way I plan human work: identify the critical path, separate independent questions, and avoid creating a merge problem just to keep everyone busy.
The review loop matters more than the first draft
AI is very good at producing a plausible first version. Production quality comes from the loop that follows.
I want a builder to explain what changed, a reviewer to challenge it against the requirements, and automated checks to judge behavior that should not depend on opinion. Tests, type checking, linting, security scans, and browser verification provide evidence. A model saying that code looks correct does not.
Review also works better when it is focused. Asking an agent to “review everything” produces broad observations. Asking it to trace authorization through one workflow or test a migration against specific legacy states produces actionable findings.
Local control is useful, but not free
Running parts of an agent workflow locally can keep project context close and make the environment more controllable. It can also require model management, hardware capacity, tool isolation, and additional evaluation.
I choose local or hosted models by the work, not by ideology. Sensitive repository analysis, repetitive classification, and bounded tasks may fit local models well. Complex reasoning may justify a stronger hosted model with carefully limited context. The architecture should make that choice replaceable.
Human oversight should be designed in
“Human in the loop” is sometimes used as a vague safety phrase. It is only useful when the loop has a defined decision.
Who approves a schema change? Who decides whether a failed test is acceptable? Which agent actions can write files, call external services, or deploy? What evidence reaches the reviewer? A person cannot supervise what the system does not make visible.
I prefer checkpoints tied to consequence. Low-risk drafting can proceed freely. Changes to data, permissions, infrastructure, or public behavior need stronger review. The goal is not to approve every keystroke. It is to place judgment where mistakes become expensive.
A smaller, better-supervised team
My mental model has changed from an autonomous software company in a box to a small, well-instrumented engineering team that happens to include agents.
The agents can research, propose, implement, test, and critique. They can reduce the cost of exploring options and take on a great deal of routine work. They still need a coherent product direction, durable technical context, reliable tools, and someone responsible for the finished system.
The advantage is not removing engineering judgment. It is giving that judgment more reach.