There are 73 live agents on this site right now, each with its own page under /agents. The obvious question from any technical reader is the right one: is that real architecture or a content gimmick? The honest answer is that it is both a system and a library, and the distinction between the two is the most useful thing I can document. This is how the agent library is structured, what "live" actually means here, and what I would consolidate if I started over.
Why 71+ agents instead of one chatbot
One do-everything marketing assistant sounds efficient and performs terribly. A prompt that can score leads, write cold outreach, and generate ad reports does all three at the level of a generalist intern, because every capability dilutes the context, the guardrails, and the evaluation criteria of the others. Decomposing "AI marketing" into named, single-responsibility agents — lead scoring is not outreach crafting is not reporting — means each agent gets a tight contract: specific inputs, a specific output shape, and a specific definition of failure. Tight contracts are what make agents testable, and testable is what makes them shippable.
The number was never the goal. The taxonomy grew agent by agent as real work demanded new capabilities, and the site simply exposes the library instead of hiding it behind a services page.
The taxonomy and the missions behind it
The agents group into four families: sales and outreach, content and SEO, ads and reporting, and customer-facing. That grouping is not editorial — it maps to the missions that actually run agents in production. IBRAHIM is the outreach mission: 11 agents running prospecting, drafting, reply classification and QA, doing 150/day outreach with a 21.8% reply rate. SARA is the ads mission, an autonomous Google Ads optimisation loop. Claude SEO Squad runs 12 agents across 6 WordPress brands. And JARVIS is the orchestrating layer — an in-development operating system whose job is to command sub-agents rather than do work itself. The /agents pages are the public index of capabilities those missions are built from.
What "live" actually means here
This is the part a listicle will never give you. Not all 73 agents are daemons running 24/7, and claiming otherwise would be the exact dishonesty that makes "AI agent" a devalued term. The genuinely live tier is the agents wired into production missions — IBRAHIM's outreach crew, SARA's optimisation loop, the SEO squad — running on schedules, calling tools, and being monitored. A second tier is agents that run on demand: real logic, real tool access, invoked when a task needs them rather than continuously. The third tier is documented patterns — full agent definitions with contracts and guardrails that a reader (or I) can deploy, but which are not currently executing against anyone's account. All three tiers are real work; only one of them is a daemon. The agent pages exist so each one can be judged on what it is.
Shared scaffold versus bespoke logic
ONE TACTIC A WEEK
Every agent definition sits on the same scaffold, and this is what keeps 73 of them maintainable. The shared layer: an input/output contract (what the agent receives, what shape it must return), guardrails (what it must never do — spend money, send unreviewed messages, invent numbers), logging of every step it takes, and a fallback behaviour for when its tools or model fail. That skeleton is identical whether the agent scores leads or writes briefs.
The bespoke layer is the actual reasoning: the domain prompt, the tool set, and the evaluation criteria. A lead-scoring agent carries scoring rubrics and CRM tools; a reporting agent carries GA4 and Ads API access and a chart vocabulary. Roughly speaking, the scaffold is 80% of the reliability and the bespoke logic is 100% of the value — you need both, but you only need to build the scaffold once.
How agents get added without the library rotting
Content sprawl is the real threat to a library this size. A new agent only enters the library through the scaffold — no freehand pages — and only after it has been run against real data at least once, because an agent that has never executed is a guess, not a definition. Definitions are versioned in git like any other code, so a prompt change is a diff, not a mystery. And agents that do not hold up get retired rather than left to mislead: a library's credibility is set by its worst entry, not its best.
What the system actually produces
The count only matters if it cashes out into running systems, so here is the cash. IBRAHIM does 150/day outreach across its 11 agents with a 21.8% reply rate. SARA took my weekly Google Ads optimisation work from 9 hours to 2 and delivered +18% ROAS quarter over quarter. The SEO squad runs 12 agents across 6 brands in production. On the client side, the Printo engagement — where several of these agent patterns earn their keep — drove 3,750 conversions on AED 42K spend. Those numbers are the difference between an agent library and an agent-themed brochure.
Lessons: agent theater and what I would consolidate
The biggest risk in this space is agent theater — naming things "agents" that are really just prompts with a logo. My working line: an agent acts, observes the result, and adjusts; a prompt template generates text and stops. Some entries in my library started life on the wrong side of that line, and promoting them meant giving them tools, state and monitoring, not a better name. The second lesson cuts against my own architecture: one well-built agent with a broader remit sometimes beats five narrow ones, because every agent boundary is a place where context gets lost in handoff. If I started over I would ship fewer, deeper agents — probably closer to forty than seventy — and let the taxonomy grow from production demand only. The library is honest because it is documented; it would be leaner if I built it again.