Inside Anjin #06: The Modularity Mindset

Anjin is built on modular AI agents - but that decision came with trade-offs. In this post, we’re exploring how we approach agent modularity, what it unlocks for users, and why treating every agent as unique is a deliberate response to the limitations we see across the current AI agent landscape.
Feature image for Inside Anjin #06: The Modularity Mindset highlighting key themes such as modular AI, agent design, system architecture.
You don’t scale AI by building one big brain. You do it by building a network of sharp, specific ones that do their job well - and know when to hand things off.

‍

There’s a lot happening in the AI agent space right now.
But if you take a closer look, most of it falls into two extremes:

  • Agent builders that require users to understand APIs, tool integrations, and memory persistence before anything useful happens. Powerful, but inaccessible for 90% of users.
  • Pre-built templates that offer vague, generalised agents (“Marketing Bot”, “Research Assistant”) - but lack the specificity needed to deliver meaningful outcomes.

At Anjin, we’re aiming for something different:
Modular, context-aware agents that are technically serious - yet practically usable.

‍

Every Agent is Treated as a Specialist

Our internal rule: never assume agent behaviour is repeatable without intention.

Each agent in Anjin is:

  • Built for a specific job - defined by a unique system prompt, config, and tooling set
  • Executed in isolation, with clean context and scoped permissions
  • Monitored and versioned independently for visibility and refinement

This isn’t a design aesthetic - it’s a structural discipline.

We’ve seen too many platforms crumble under shared logic and leaky abstractions.
We’d rather work harder up front so users don’t hit weird edge cases later on.

‍

What Modularity Unlocks

Modular design isn’t just about clean architecture. It’s about delivering sharper tools and more flexible workflows.

This approach gives us:

  • Precision: Each agent has a clearly defined purpose and prompt strategy
  • Composability: Agents can be chained or layered for complex, multi-step flows
  • Security: Tokens and API credentials are bound to the agent instance
  • Debuggability: We can trace outcomes at the agent level, not just the session
  • Performance tuning: Each agent can be optimised for its task (speed, depth, creativity)

For example, one of our internal flows involves three agents running in sequence - each analysing, passing context, and executing tightly scoped tasks using third-party APIs and embedded memory. The entire operation runs server-side, with no client exposure. That’s the kind of flow we’re optimising for.

‍

What This Breaks (And Why It’s Worth It)

This approach isn’t frictionless. It introduces complexity we have to own:

  • No shared memory by default - all context passing must be explicit
  • No frontend shortcuts - execution happens in secured backend logic
  • No assumptions - each agent must be individually tested and validated

It’s slower to build. But the result is a platform that can scale intelligently - with agents that don’t just “work”, but work well in their intended domain.

‍

Under the Hood: Structuring Modularity

Without giving away too much, here’s how we make modularity real:

  • Supabase handles data and user state, enforced with RLS
  • Supabase Edge Functions run all agent logic-execution, validation, logging
  • Custom tool integrations like SEMrush or internal utilities are assigned per-agent
  • Memory and caching are scoped and stored in SQLite or structured stores per agent run
  • System prompts and parameters are version-controlled for reliability

Each agent endpoint (/agents/[agentId]) is a unique, auditable execution unit.

We’ve documented the wider system flow in Inside Anjin #01 and Inside Anjin #04, but the short version is this: we’re not guessing here. We’ve built agents that hold up in real-world usage.

‍

What This Means for Users

For users, this translates to three big things:

  • Confidence: Every agent is scoped, traceable, and intentionally designed
  • Clarity: No hidden behaviours or generic templates pretending to be smart
  • Customisability: Power users can request or build chains that reflect their exact needs

You’re not getting a “copilot”. You’re getting a stack of skilled collaborators - each one trained for a task, and integrated safely.

‍

Final Thought: Modular ≠ Minimal

Modularity isn’t a way of doing less. It’s a way of doing the right things, better.

At Anjin, we’re building systems that are harder to build - but far more valuable to use.
That’s what modularity means to us. And we’re just getting started.

‍

‍

Want to explore what modular agents can actually do?
Join the community, share your use case, or read more from the journey so far:

‍

Continue reading