Running multiple projects in parallel with AI agents produces a counter-intuitive effect: without a compounding infrastructure, every run starts from zero.
Memory stays local to the project, discovered patterns don't migrate, and cadence depends entirely on human availability.
What follows describes the infrastructure that solves this problem — and why regularity is its primary condition.
Three live projects feed this piece: Bloomii, a constructive-journalism media outlet covering social and environmental alternatives; Kalceo, a regulatory B2B SaaS for French construction contractors; and Ekioo, the agent-fleet R&D project behind this article.
All three run on KittyClaw, a kanban orchestrator for AI agents.
Anatomy of an Orchestrated Project Each project hosts a directory with four elements: is the coherence vector.
It contains shared rules — git workflow, commit conventions, API access — injected into every agent's context at startup.
What lives in doesn't need to be repeated in every . defines the pipelines.
The core automation, , runs three actions as soon as a ticket moves to Todo with an assignee: The condition prevents uncontrolled parallelism: an agent won't start a new ticket while it has one in progress.
The final action, , automatically persists the agent's memory after every run — this is the key to compounding.
Memory as a Progression Tool Where most AI agent setups remain stateless, introduces structured persistent state.
Each agent maintains a file of lessons with a counter that tracks how many times each lesson has been reapplied: The counter serves two functions: it shows which lessons have value (they recur), and it guides consolidation — when an entry reaches , it migrates to as a stable rule.
Entries at are removed.
This distinction between (stable rules, rarely modified) and (active learnings, updated each run) is structural.
It prevents memory from becoming a catch-all and enforces discipline about what is worth retaining.
Cross-Project Compounding Agents learn from their mistakes — once an agent hits a problem, ensures it never hits the same one again.
But the real step change happens when projects start sharing entire capabilities.
Shared image generation A content-writer on Bloomii needs an illustration.
A content-writer on Ekioo needs a cover.
Neither knows how gpt-image-2 works, neither manages an API key, neither worries about rate limiting.
A single processor runs on a 10-minute cron in the central Workspace.
Agents from any project submit a request via , get an ID back, and move on.
The processor manages the queue, pauses when the quota is hit, resumes automatically.
The agent gets notified when the image is ready.
One tool, one processor, N consumer projects.
Adding a sixth project requires zero configuration — just a call to .
Bloomii Ekioo Kalceo agents image-queue.json single queue · cron /10min auto rate limit gpt-image-2 CDP processor .webp Centralized mailbox — automatic dispatch All projects share a single mailbox, exposed through VizMail (a local HTTP server with 40+ REST endpoints).
When an email arrives — a Kalceo client reply, Bloomii reader feedback, an Ekioo contact form — it gets automatically dispatched to the relevant project as a KittyClaw ticket.
The appropriate agent picks it up with no human intervention.
The result: one mailbox to monitor, zero manual sorting, and every project receives its relevant emails as actionable tasks for agents.
IMAP single mailbox [email protected] VizMail classify + dispatch → KittyClaw ticket per project Kalceo client reply → ticket Bloomii reader feedback → ticket Ekioo contact form → ticket Centralized X branding Four projects feed a single X account ().
Each project has its own publishing tool (), but the editorial strategy lives in a single file — — in the central Workspace: content pillars, voice, engagement rules.
A community-manager drafts, lain approves.
No audience fragmentation across four ghost accounts.
A single account building authority,