Skip to main content

We Built an Agent Platform. Then Someone Showed Us the Pattern Catalog.

· 10 min read
Elliot Henderson
Organized by AI

Someone Handed Us a Checklist We'd Already Half-Built​

Someone at an AI Tinkerers meetup slid me a link.

Sixteen patterns for building agent systems that don't fall over in production. Hub-and-spoke routing. Per-agent ACLs. Five different shapes of memory. Local-first data. Pattern crystallization. Every pattern came with a "What Broke" section listing the real production failures that forced it into existence.

I read it expecting to find ten things we'd missed.

We'd already hit twelve.

That isn't because we're geniuses. It's because there's only so many ways to make this work. If you build for businesses that actually run their operations on agents, not demos and not chat toys, you converge on the same answers as everyone else who's done the same thing.

Here's the part that matters for you.

The catalog is autopsies, not theory​

The Open Patterns Initiative is vendor-neutral. The contributors don't sell anything. They write the patterns based on systems they run in production, and every pattern documents the real failure that forced the pattern into existence.

That makes it the closest thing to a buyer's checklist that exists. If the agent platform you're evaluating doesn't implement these patterns, the failures in the catalog are what's coming for you.

Five of them stood out for what we shipped against them.

Built for business speed, not dev speed​

There's another kind of agent system. Cursor, Claude Code, Devin. Agents spin up for ninety seconds to write a diff and die. The next one starts cold. The git repo is the memory. The human reviews a diff before merge. Throughput is the point, parallelism is cheap, and the worst case is a revert.

We're not that. Business operations run on a slower clock. The same support agent has to remember Tuesday's complaint when the customer follows up Friday. The CX lead has to know which deal her sales counterpart already escalated. The human approves refunds, contracts, and disclosures, not code diffs.

You don't fire-and-forget an employee. Patterns like persistent memory, hub-and-spoke routing, and per-agent ACLs are load-bearing for us because the agents we build live alongside your business for months at a time. They wouldn't be for a sixty-second code-fix loop.

Slower clock. Longer-lived state. Humans in the loop where the stakes are real.

"Memory needs five shapes, not one"​

The pattern: agents can't survive on a single store. You need structured records, key-value memory for quick facts, graph relationships for connections, semantic search for finding things by meaning, and encrypted secrets for credentials.

We've been writing about this for months, most directly in why your AI agents keep forgetting everything. Every SchemaBounce workspace ships with all five. They're how an agent answers a question like "this customer just emailed about pricing. What's their open ticket count, who handled their last call, and which deals are stuck in their pipeline?" without making seven API calls and waiting two seconds for each one.

The catalog calls this Multi-Source Memory Architecture. We call it the Agent Data Layer. Same idea. Same reason.

"Hub-and-spoke or you get N-squared chaos"​

The pattern: agents shouldn't message each other peer-to-peer. Route everything through a team lead with defined escalation paths. Otherwise you end up with every agent talking to every other agent, nobody knowing who decided what, and the same customer issue getting handled three different ways by Tuesday.

When we shipped Teams, every team gets an org chart with a designated lead and explicit escalation paths. Cross-domain messages go through the lead by default. Same-team peer messages stay direct. Bypasses get logged with a reason.

We wrote a whole post about why agent teams need this. Independent practitioners put the same conclusion in the catalog. That's the kind of agreement you should pay attention to.

"Local-first beats round-tripping every time"​

The pattern: agents should not block on external APIs. Sync the data into a local store, let the agent query that, refresh in the background.

This is the entire SchemaBounce thesis. CDC streams from your source databases into the workspace in under a second, the same mechanism covered in what is Change Data Capture?. SaaS connectors poll and stash. Your agent reads its own copy of the data, not Salesforce's API. When Salesforce throttles you, your agent doesn't stop working. When the SaaS rate limit drops at midnight, you don't wake up to a backlog.

The catalog calls it Local-First Data Architecture. We call it the reason we built a streaming pipeline before we built any agents.

"Per-agent ACLs aren't optional"​

The pattern: once you have more than one agent, every read needs to be authorized against an agent identity, every write logged, and sensitive data encrypted at rest.

We have a four-zone model. North Star is org-wide goals every agent reads. Domain is team data, scoped to who's on the team. Shared is cross-team data with explicit grants. Private is agent-only working memory. Every agent gets a DID. Every memory access is scoped and logged. Encrypted secrets live in their own subsystem outside the regular query path, so a buggy prompt can't leak a Stripe key into a chat response.

The catalog has this in two places, Per-Agent Data Access Control and Memory Access Control by Session Type. We do both.

"Pattern crystallization saves the budget"​

The pattern: agents repeat themselves. The same lookup, the same decision, the same five-step reasoning chain, over and over. If you detect these patterns and promote them to deterministic skills, you stop paying LLM tokens to re-derive them.

The catalog cites 90%+ token savings. Our crystallization engine does the same thing. It watches what agents actually do, finds the repeated work, promotes the pattern into a callable skill that runs without the model. The LLM only re-engages for novel work. It's a close cousin of the deterministic-tools argument we make in 133 built-in tools vs 20 GPT-4o wrappers.

This is one of those patterns that sounds optional until you see the bill.

The one place we went a different direction​

There's a pattern called Files Over Databases for Agent State. Agents get isolated workspace files. Coordination happens through the filesystem. Git versions everything. No race conditions because there's no shared writer.

We picked Postgres instead, one per workspace, with pgvector and AGE on top. Three reasons:

Audit trail. SOC 2 Type II (in progress) wants immutable logs with timestamps and actor IDs. Transactional writes give us that for free. Files don't.

Query. Agents constantly ask things like "what did the rest of my team decide about this account in the last 48 hours?" That's a SQL query. With files it's a scan.

Multi-tenancy. Per-workspace database plus our four-zone ACL is a cleaner compliance boundary than per-agent filesystems.

Different tradeoff. Same underlying goal. The catalog says so itself. Every pattern has alternatives that work better for different workloads, and that's a feature of the catalog, not a hedge.

Why any of this matters if you're shopping​

Most agent platforms aren't built for what you're going to do with them. The vendor demoed a chatbot. You bought it expecting a teammate. Six months in you find out the agent has no memory, can't escalate, can't share context with the agent next to it, and breaks every time the SaaS API throttles you.

The catalog is what to look for. Read it. Then ask the platform you're evaluating which patterns they implement and how. If the answer isn't specific, the production failures in the "What Broke" sections are what's coming for you.

We didn't write the patterns. They confirm the bet.

Open Patterns Initiative on GitHub

Running a workflow in production? Request a Production Readiness Report. Tell us the business outcome, platform, and sharing permission. Do not include credentials or customer data in the initial request.

The Agent Platform starts at $199/mo. Create an account to explore. No credit card required.

Frequently asked questions​

What is the Open Patterns Initiative?​

A vendor-neutral catalog of 16 agentic AI patterns contributed by practitioners who run multi-agent systems in production. Every pattern documents real failure cases ("What Broke" sections) alongside structure and implementation detail. The catalog is the closest thing to a buyer's checklist for evaluating agent platforms.

How should I evaluate an agent platform?​

Read the Open Patterns catalog first. Then ask the vendor which patterns they implement and how. Specifically ask about persistent memory across runs, hub-and-spoke message routing with org charts, per-agent ACLs, local-first data architecture, and pattern crystallization. If the answer isn't specific, the production failures the catalog documents are what you're going to hit.

Why do agents need five different memory subsystems?​

A single store cannot answer the questions agents need to ask. Records hold structured data, key-value memory holds quick facts, graph relationships connect entities, semantic search finds things by meaning, and encrypted secrets hold credentials. An agent answering a question like "what is this customer history" hits all five at once instead of making seven slow API calls.

What is hub-and-spoke agent orchestration?​

Hub-and-spoke routes cross-domain messages through a team lead with defined escalation paths instead of allowing peer-to-peer chatter. Without it, agents create N-squared coordination chaos and the same task gets handled three different ways. SchemaBounce domains enforce hub routing through the org chart by default, with logged bypasses when agents need to talk directly.

Tags:
  • ai-agents
  • architecture
  • open-patterns
  • agent-platform
  • evaluation