DEV Community: Mostafa Fathy

The Multi-Agent Architecture for Education

Mostafa Fathy — Wed, 01 Jul 2026 14:08:02 +0000

The Problem With One Prompt

When we first started automating curriculum production , the obvious move was to throw a big prompt at Gemini and ask it to produce a full lesson.

It worked - sometimes. The quality was inconsistent. A great lesson on Monday, a mediocre one on Tuesday, and nobody could explain why.

The root issue: one LLM doing everything is like one developer handling design, backend, QA, and deployment simultaneously. You get output, but it's noisy.

The Multi-Agent Solution

We split the pipeline into four specialized agents, each with a narrow job:

1. Planner Agent
Takes the learning objective and breaks it into a structured outline - topics, subtopics, learning outcomes, estimated time per section. No content yet, just architecture.

2. Writer Agent
Receives the outline section by section and writes the actual content. Has no visibility into other sections - this forces consistency through structure, not context.

3. QA Agent
Reviews the full draft against the original learning objective. Flags gaps, redundancies, and places where the content drifted from the outcome. Returns a structured diff.

4. Formatter Agent
Takes the approved content and outputs it in the exact format our LMS expects - SCORM metadata, section markers, media placeholders.

Why LangGraph

LangGraph lets us define the flow as a state machine - each agent is a node, and we can branch conditionally. If QA flags major issues, the loop goes back to Writer. If it passes, it moves to Formatter.

This is something you can't do cleanly with a linear LangChain pipeline.

`python
from langgraph.graph import StateGraph

workflow = StateGraph(CurriculumState)
workflow.add_node("planner", planner_agent)
workflow.add_node("writer", writer_agent)
workflow.add_node("qa", qa_agent)
workflow.add_node("formatter", formatter_agent)

workflow.add_conditional_edges("qa", should_revise, {
"revise": "writer",
"approve": "formatter"
})
`

Results

After switching to this architecture:

Content consistency score went from 6.8/10 to 8.5/10 (internal rubric)
Average production time per lesson dropped by ~40%
QA revision loops average 1.2 iterations instead of 3+

The key insight: specialization improves quality even for AI agents. A model doing one focused task outperforms the same model doing five tasks in a single prompt.

Originally published at mostafafathy.com

Why I Treat the Curriculum Like a Software Architecture

Mostafa Fathy — Wed, 01 Jul 2026 14:07:22 +0000

The Insight That Changed How I Work

I spent years thinking about curriculum as content â€” topics to cover, videos to produce, exercises to write.

Then I started building software systems at Armstrong, and something clicked: a curriculum is an architecture problem, not a content problem.

Both have:

Components that do one job (a lesson, a microservice)
Dependencies that must be satisfied in order (prereqs, API contracts)
Failure modes that cascade if not handled (a confusing lesson breaks everything after it)
Interfaces between parts (how a module hands off to the next)

The Problems This Reframing Solves

1. The "Zipped" Curriculum Problem

Most curricula are built like a monolith â€” everything is coupled. Change one topic and you have to rewrite three lessons. Add a new module and the learning path breaks.

Software has solved this with microservices. We applied the same idea: every lesson is self-contained. It has defined inputs (what the learner must know before), defined outputs (what they can do after), and no hidden dependencies.

Now we can swap, update, or reorder lessons without touching anything else.

2. The No-Tests Problem

Software engineers write tests. Instructional designers... review? Hope?

We introduced learning outcome validation at the unit level â€” every lesson has an exit assessment that maps directly to its stated outcome. If learners fail the assessment, the lesson failed, not the learner.

This is just unit testing for education.

3. The "Who Owns This" Problem

In a big curriculum, nobody knows who's responsible for which part. Bugs (bad content, outdated info) go unfixed for months.

We use a CODEOWNERS-style assignment. Every module has an owner. Changes require review from the owner. Same as a pull request.

What This Looks Like in Practice

Our curriculum now has:

A dependency graph (built in Notion, visualized in Figma)
Module specs that define inputs/outputs before a single word is written
An automated QA pipeline (our AI system) that checks new content against the spec
A versioning system â€” curriculum v2.3, not just "the updated version"

The Result

We went from ad-hoc content production to a system that can onboard a new SME in two days and have them producing spec-compliant content by day three.

The curriculum is no longer a document. It's a system. And systems can be improved systematically.

Originally published at mostafafathy.com

Why Nobody Finishes Your 1-Hour Video

Mostafa Fathy — Wed, 01 Jul 2026 14:01:18 +0000

The Attention Problem Is a Design Problem

Originally published at mostafafathy.com

The Information Dump Problem

Mostafa Fathy — Wed, 01 Jul 2026 14:01:15 +0000

The Mistake Every New EdTech Platform Makes

Originally published at mostafafathy.com