di-marketing-ai: The Baton-Passing Marketing Orchestrator That Keeps AI Specialists Focused
A deep dive into a multi-agent system that turns marketing goals into a planned sequence of research, strategy, and creative execution without letting the context window balloon out of control.
- di-marketing-ai treats marketing as a relay of specialist decisions, not a single prompt stuffed with everything at once.
- Its baton pattern compresses each agent’s output before the next handoff, which is the repo’s main defense against context overload.
- The planner is opinionated on purpose, because a marketing workflow needs ordering and limits more than unlimited freedom.
- The hybrid UI and memory layer show a product that wants to support both delegation and hands-on control while learning which agent chains recur.
The clever part of di-marketing-ai is not that it uses agents. Plenty of repos do that. It is that the system refuses to treat a marketing workflow like one long conversation. Instead, it turns the job into a relay, where each specialist gets a narrow baton, does one thing, and passes on only the useful residue.
The Clever Part: Every Agent Gets a Baton, Not a Dump Truck of Context
That baton is the repo’s most important design choice. In the backend pipeline, each agent produces a full result, then a cheaper model compresses it into a short handoff, capped at roughly 150 characters, before the next agent starts. The point is not just cost control. It is to keep the next agent from inheriting a transcript landfill.
That matters because multi-agent systems fail in a very specific way. They do not usually fail from lack of intelligence. They fail because every new step inherits too much noise. `compress_context` is a practical answer to that problem, and it is more interesting than a generic agent chain because it creates a real constraint: each specialist must act on a distilled brief, not a sprawling memory dump.
The architecture also makes the workflow legible. The repo’s pipeline follows a simple sequence: plan, execute, synthesize. That sounds ordinary until you notice that the plan is constrained, the execution is staged, and synthesis is its own step rather than a side effect. In other words, the system behaves less like a chatbot and more like a production line.
A Marketing Goal Becomes a Sequence of Specialized Decisions
| Monolithic chatbot | di-marketing-ai |
|---|---|
| One giant prompt absorbs the whole task. | A planner decomposes the task into 2 to 4 ordered agents. |
| Every step sees the full transcript. | Each step receives a compressed baton. |
| The model improvises across roles. | Domain-specific agents act like research, strategy, or creative specialists. |
| The user mostly waits for one answer. | The frontend can stream planning and execution as separate phases. |
The planner is opinionated in a useful way. It does not pretend every sequence is equally valid. The repository description shows ordering rules, such as research before creative, and it limits the chain to a small number of agents. That is not a missing feature. It is the system admitting that marketing work has natural dependencies.
There is also a reliability layer hiding behind the intelligence. The planner includes fuzzy parsing so malformed model output does not break the flow. That is the kind of detail that makes an AI system feel like software instead of a demo. It expects the model to be useful, but not perfectly obedient.
Why These Agents Feel More Like a Team Than a Prompt Chain
The repo gets this feeling from knowledge injection. Rather than relying on a generic model to infer everything from scratch, it prefixes prompts with domain expertise from `di-knowledge.json` and role-specific instructions from the agent registry. That means the research agent, strategy agent, and activation agent are not just different names. They are different working assumptions.
This is where the marketing frameworks matter. The prompts can embed familiar structures such as RTB and SCAMPER, which gives the system a vocabulary for making decisions instead of just generating copy. The result is a specialist team with opinions, not a blank canvas with costumes.
| Generic assistant | Knowledge-injected agent |
|---|---|
| Starts from a blank general-purpose model. | Starts with domain-specific marketing knowledge. |
| Must infer the task frame on the fly. | Carries a role with an explicit job to do. |
| Can drift across disciplines. | Stays inside a narrower decision lane. |
| Feels like one broad helper. | Feels like a team with different responsibilities. |
The Planner Is Opinionated, and That Is the Point
`plan_task` is where the repo stops pretending orchestration is neutral. It chooses agents dynamically, but inside a bounded frame. The planner asks for a small set of specialists, enforces an order, and then hands execution to the pipeline. That keeps the system from becoming an unstructured swarm.
# Simplified from the planner and pipeline pattern
plan = plan_task(goal)
for agent in plan.agents:
full_output = run_agent(agent, baton)
baton = compress_context(full_output, max_chars=150)
final = synthesize(plan.outputs)
The fuzzy parser is an underrated piece of the design. If the LLM returns slightly malformed JSON, the parser tries to recover instead of failing loudly. That is exactly the right instinct for production AI: be strict about the workflow, forgiving about the model’s formatting.
This is also why the system feels closer to a workflow engine than a chat interface. A chatbot invites improvisation. A planner invites sequencing. `di-marketing-ai` is clearly betting on sequencing.
Memory That Remembers Patterns, Not Just Prompts
The memory layer turns the repo from a one-off executor into something more adaptive. `memory_store.py` tracks successful agent sequences, so repeated patterns can accumulate weight over time. That means the system is not only doing work. It is observing which workflows recur.
That is a small but important clue about where this kind of software goes next. Today the memory layer tracks patterns. Tomorrow it could bias planning, reduce repeated mistakes, or surface common winning sequences. The repo is already behaving like a system that wants to learn from its own routing choices.
Two Front Ends, Two Modes of Trust
| Mode | What the user wants | What the interface gives |
|---|---|---|
| Orchestrate | Delegate the whole workflow. | A hands-off path where the system manages planning and execution. |
| Agents | Work directly with a specialist. | A hands-on path for talking to individual personas. |
| Hybrid UI | Move between control and automation. | A product that supports both oversight and direct use. |
That split is smart. It acknowledges a basic truth about AI tools: sometimes users want the machine to drive, and sometimes they want to inspect the passenger seat. The repo’s two modes are not redundant. They represent two trust levels.
The Shogun Sub-Module Is a Side Quest With a Real Design Lesson
The `multi-agent-shogun` directory is easy to dismiss as a stylistic detour, but it reveals something useful. Shogun, Karo, and Ashigaru are not just decorative names. They encode hierarchy. That is a reminder that naming is part of system design, especially in agent software where role clarity matters as much as code paths.
The larger lesson is simple. `di-marketing-ai` is not trying to build one omniscient marketing brain. It is trying to build a disciplined relay where knowledge, order, and compression matter as much as raw model capability. That is the thesis worth keeping.
