Most teams building AI agents make the same mistake. They write one giant system prompt that tries to hold every instruction, every edge case, and every domain rule in a single context window. It works in the demo, then falls apart in production. The agent does the right thing on Monday and something baffling on Tuesday, and nobody can say why.
The problem with one giant prompt
A monolithic prompt is hard to debug because everything touches everything. When the model behaves unexpectedly, you cannot isolate which instruction caused it, because they all load at once and compete for attention. Add a new rule to fix one behaviour and you risk breaking three others. For an Australian business trying to put an agent in front of customers or staff, that kind of drift is the difference between shipping and stalling.
What Doubao reportedly gets right
ByteDance's Doubao is a useful case study because of its scale. Public reporting put Doubao above 300 million monthly active users in 2026, up from around 226 million at the end of 2025. An assistant serving that many people cannot afford flaky behaviour, so the way it is put together is worth studying.
Community analysis of Doubao's agent stack, shared through the AI Builder Club newsletter, describes roughly two dozen modular skills spread across a few hundred files rather than one enormous prompt. ByteDance has not published these internals, so treat the exact counts as reported rather than confirmed. The structure is the lesson, and it is the same idea Claude Code is built around.
In that reported design, each skill owns four things:
Routing rules. The explicit conditions that decide when the skill activates, so the wrong skill does not load at the wrong moment.
Domain knowledge. The context specific to that skill's job. A billing skill knows billing. A customer-lookup skill knows the customer schema. Neither carries the other's baggage.
References and scripts. Tooling scoped to the skill, such as a linting config for a code-review skill or calendar patterns for a scheduling skill.
Boundaries. What the skill will explicitly not do. Knowing where to stop prevents the context bleed that makes agents unpredictable.
Skills hand off to each other through explicit calls rather than a shared pile of global state. That separation is the entire point.
The Claude Code parallel
Claude Code's skill system maps almost directly onto this pattern, which is why the comparison is more than a curiosity:
Your CLAUDE.md acts as the top-level router that holds shared conventions.
Each skill file is a scoped domain module you can read on its own.
Hooks provide event-driven triggers, the working equivalent of routing rules.
Subagents handle delegation when a task needs a fresh, focused context.
The catch is that most teams using Claude Code still run a single sprawling CLAUDE.md with everything in it. They have the modular system available and use it like a monolith. When something breaks, they are back to the same guessing game.
Applying the pattern in Claude Code
You do not need a rebuild to fix this. A few deliberate steps get most of the benefit:
Audit your current CLAUDE.md. Count the distinct domains it covers. More than two or three and you have a monolith.
Extract one skill per domain, such as code quality, API integration, documentation, and testing. Each file should be readable without referencing the others.
Write routing conditions. Put explicit trigger conditions at the top of each skill so it loads only when it should.
Define boundaries. State what each skill will not handle so context stops bleeding across jobs.
Test in isolation. If a colleague can grasp a skill's full scope without reading anything else, it is properly decoupled.
What this is worth to an Australian team
Agent reliability is the number one concern we hear from Australian businesses evaluating Claude Code. The failure mode of a monolithic prompt is not a dramatic crash. It is quiet, expensive drift. A mid-size Sydney software team can lose $45,000 a year to engineers re-running, second-guessing, and patching an agent that behaves differently every week. Add a stalled rollout that was meant to save a support team $120,000 in annual handling costs, and the monolith becomes the most expensive shortcut on the roadmap.
Modular skills are not more work to build. They are easier to maintain, test, and hand to a new team member, because each piece stands on its own. The hour you spend splitting one skill pays back every time you debug or extend it.
Where to start
Pick the one domain in your CLAUDE.md that causes the most trouble and pull it into its own skill this week. Give it a clear trigger and a clear boundary, then watch whether the unpredictable behaviour settles. If you want a second set of eyes on how to structure your skills from the start, book a session with our team.
Source: community analysis shared via the AI Builder Club newsletter, June 2026. Doubao's user figures come from third-party reporting; its internal skill counts are community-reported and not officially confirmed by ByteDance.
