22 AI agents for compounding pharmacy — inspired by AIOS-core

[Fabiorfonseca]

Hey everyone! I'm Fabio, a pharmacist and founder of Carpe Diem Compounding Pharmacy in Brazil. Writing from ES (Espirito Santo) — English isn't my first language, but I wanted to share how aios-core directly influenced the evolution of our agent ecosystem, which operates in a very different domain from software development.

Context

Since December 2025, we've been building an ecosystem called TALS/AI — 22 specialized agents for compounding pharmacy. The stack is 100% Anthropic (Claude Code + MCP), with agents defined in pure Markdown and centralized governance in YAML.

Current numbers:

• 22 agents with defined personality and territory (Giovanni formulates, fabIA assists patients, LOKI analyzes data, TOM guards the brand...)
• 9 deterministic engines (Scientific, Incompatibility, pH, Similarity, Calculation, Inventory...)
• 5 repositories on corporate GitLab
• PostgreSQL with 81 tables (ETL from the pharmacy's Firebird ERP)
• 2 MCP Servers active (calculator + SQL Server)

How we found AIOS-core

We were in a consolidation phase — the ecosystem worked, but it felt like it lacked operational robustness. When we discovered aios-core (v4.0), I ran a detailed comparative analysis and identified 5 operational gaps that you had already solved and we hadn't:

Gap	AIOS-core has	TALS didn't have
Self-Critique	QA agent with post-execution review	Agents finished tasks without self-verification
Schema Validation	Formal agent/task structure	YAMLs without validation schemas
Recovery System	Retry + fallback in pipelines	Zero checkpoints — failure = total loss
QA Evolution	Multi-phase quality gates	No automated checklist
Squads	Domain-composed teams	Isolated agents, no grouping

What we implemented (inspired by you)

In a single work session (Feb 14-15), the flow was: ALEX (our CTO advisor agent) analyzed the gaps → prioritized → generated specs → Andrew (our agent architect) implemented everything.

1. Post-Execution Gate (inspired by the QA agent)

We added a self-critique block to our 6 main slash commands. Before completing any task, the agent verifies:

• Did I only modify files within my territory?
• Did I break backward compatibility?
• Did I respect governance rules?
• Did I document the work?
• Do I need to return results to someone?

2. Schema Validation (inspired by AIOS formal structure)

We created 4 formal YAML schemas:

• agent-schema.yaml — required fields for every agent
• skill-schema.yaml — skill structure
• handoff-schema.yaml — agent-to-agent handoff protocol
• recovery-checkpoint.yaml — recovery state

3. Recovery System (inspired by your retry/fallback)

• MEMORY/recovery/ directory for 5 tier-1 agents
• Checkpoint schema with state machine (running → failed → retrying → completed)
• Max 2 retries, then fallback with user notification

4. /validar Skill (inspired by quality gates)

An automated QA with 6 phases and a 0-100 score:

• F1: Territory Check (20pts)
• F2: Schema Validation (20pts)
• F3: Backward Compat (20pts)
• F4: Dependency Impact (15pts)
• F5: Recovery Check (10pts)
• F6: Documentation (15pts)

Score >= 80 = approved. < 80 = fix before closing the task.

5. Squads (directly inspired by AIOS Squads)

5 composed squads:

• Pharmaceutical (Giovanni, fabIA, PEDIA, MAF) — formulation + validation + production
• Marketing (TOM, ALPH, TETTE, TATI) — brand + campaigns + content
• Governance (ALEX, Andrew, JUDITE, NERO) — architecture + governance
• Data (LOKI, SARAIVA, FIN) — analytics + pricing + finance
• Regulatory (ADi, HARVEY) — ANVISA (Brazilian FDA) + pharmaceutical law

Where we diverged

Our ecosystem differs from AIOS in a few architectural decisions that might be interesting to you:

Markdown-first (no code)

Our agents are defined entirely in Markdown. The main prompt (CORE) is ~100-150 lines. Skills are SOPs (Standard Operating Procedures) in .md files. This gives us 100% portability — if we switch orchestrators tomorrow, 90% of the ecosystem comes with us.

Handoff System with chaining

We have a task-passing system between agents with:

• Formal YAML with from_agent, to_agent, context, return_path
• 3 modes: result_return (back to origin), chain (forward to next), terminate
• Automatic routing via ROUTING.yaml
• Real example: Fabio → ALEX (analyzes) → Andrew (implements) → Fabio (receives result)

Territory-based Governance

Each agent has a can_modify field — explicit paths it's allowed to alter. If it tries to modify outside its territory, it's blocked. This prevents the classic problem of agents stepping on each other's toes.

MCP per need

Out of 22 agents, only 2 use MCP. The other 20 work with in-process services or no external integration. The rule is: create an MCP server only when the agent needs external integration. Pragmatism > feature bloat.

The domain: compounding pharmacy

Perhaps the most interesting part is the domain. Our agents deal with:

• Compounding formulation — capsules, creams, solutions with real pharmacotechnical calculations (density, Carr Index, Hausner ratio)
• Chemical incompatibilities — 1,000+ cataloged interactions
• Scientific dossiers — PubChem, DrugBank, LactMed as sources
• Pricing — 35% COGS methodology per dosage form
• Regulatory — ANVISA (Brazilian FDA), RDC 67/2007, controlled substances

It's a vertical use case very different from software development, but AIOS-core's multi-agent orchestration architecture turned out to be surprisingly applicable.

Thank you

Your work on aios-core has been an important reference for us. Especially:

• The idea of Squads as composed teams was a game-changer
• The recovery system was a critical gap we hadn't even noticed
• The quality gates made us rethink how we validate agent output

Congrats on the project and its rapid growth.

If you're curious about how a multi-agent ecosystem works outside the dev domain, I'm happy to share more — including a deeper technical write-up on any of these patterns if there's interest.

---

Fabio Resende Fonseca
Pharmacist (CRF-ES 2116)
Carpe Diem Compounding Pharmacy — Brazil

[Fabiorfonseca]

Update: Context Engine + Session Bridge (inspired by SYNAPSE)

After posting here, we went deeper into the SYNAPSE architecture — studied the 8-layer pipeline, the UAP Session Bridge, bracket-aware injection, and the diagnostics system. Here's what we built from those patterns.

The problem we had

Our agents were forgetting their rules in long sessions (40+ prompts). Our original hook ("Enforcement Brutal v1.0") injected everything on every prompt — governance, territory, rules, handoffs — all at once, always the same. It was like shouting louder instead of speaking better.

What SYNAPSE taught us

Three patterns we didn't have:

1. Layered injection — Instead of dumping all context at once, separate it into layers and activate each one based on need
2. Bracket-aware adaptation — The counter-intuitive insight: inject MORE context when the context window is depleting, not less. When an agent is "forgetting", reinforce the rules
3. Session state as a formal entity — Not just "which agent is active" but the full session: squad, handoff, prompt count, bracket, activation history

What we implemented

We translated SYNAPSE's patterns to our stack (Bash + YAML, no Node.js):

Context Engine (5 layers, <50ms):

Layer	Name	Source	When
L0	Governance	Rules YAML	ALWAYS
L1	Territory	Agent's can_modify paths	ALWAYS
L2	Agent Rules	Top 5 critical rules per agent	ALWAYS
L3	Squad	Squad members + workflow	MODERATE+
L4	Handoff	Active handoffs for this agent	MODERATE+

We simplified from 8 layers to 5 — removed keyword recall (L6) and star-commands (L7) as unnecessary for our domain.

Bracket tracking:

Bracket	Prompt count	Behavior
FRESH	0-25	Lean injection (L0+L1+L2 only)
MODERATE	26-50	Full injection (all 5 layers)
DEPLETED	51-75	Full + rule reinforcement
CRITICAL	76+	Full + wrap-up warning

We use prompt_count as a proxy for context usage instead of context_percent — simpler, no runtime dependency, good enough for our use case.

Session Bridge:

Evolved from a file containing just "giovanni" to a full session.yaml:

session_id: "ses-260216-1430"
active_agent: "giovanni"
active_squad: "farmaceutico"  # auto-resolved from SQUADS.yaml
active_handoff: null
prompt_count: 34
context_bracket: "MODERATE"
activation_history:
  - agent: "alex"
    deactivated_at: "2026-02-16T14:00:00Z"
    prompts: 12

With graceful degradation: if the file is corrupted, it recreates from scratch. If missing, operates without an agent. Never blocks.

Performance

Bracket	Layers	Time
FRESH	3	30ms
MODERATE	5	46ms
CRITICAL	5 + warning	44ms

All within the 100ms budget that SYNAPSE targets.

What we can give back

A few observations from adapting SYNAPSE to a non-dev domain:

1. 5 layers may be enough — L6 (keyword recall) and L7 (star-commands) add complexity that smaller ecosystems don't need. Consider making them optional.
2. prompt_count works as a bracket proxy — Not every environment exposes context_percent. A simple counter is a viable fallback.
3. Bash is viable for <50ms budgets — The engine doesn't need to be Node.js. Shell scripts with jq + sed + grep handle 5 layers comfortably.
4. YAML over JSON for human-operated systems — When the operator is a pharmacist (not a developer), readability matters more than parsing speed.

We'll keep posting updates as we implement Phase 2 (Runtime Diagnostics inspired by your 10-collector system).

---

Fabio Resende Fonseca — Carpe Diem Compounding Pharmacy, Brazil

[serraoednei]

Ola Fábio, Como esta usando esses agentes na sua farmácia? Fiquei curioso para ver como as pessoas usam, aqui uso 2 apenas que o pessoal utiliza no atendimento com todo o conhecimento de duvidas que foram tiradas com nossa farmaceutica tipo um banco de dados e outra para utilizar para duvidas no laboratorio.

[guscherer]

Excelente trabalho, orquestração de gente grande. Parabéns!!!. Depois que descobri o AIOS eu também mudei a mentalidade em relação aos meus projetos e agora está fluindo muito mais rápido e conciso