In regulated environments like financial services: Every agent action must be observable, reviewable, and defensible after the fact. In part I we took a bet on the idea of agentic primitives or "batteries included" for implementing consistent, reliable agentic systems.
Every team building a serious agentic system implements some version of these primitives. Usually differently in every iteration, because it's not their core focus. This constant, custom rebuilding of essential infrastructure is like a race team having to invent a new Pit Crew for every single pit stop.
In part II we will go deeper in defining these primitives. The primitives above aren't independent. Their value compounds through integration:
- Memory + Work Graph: Tasks know what context is relevant; retrieval is scoped to the work at hand.
- Messaging + Resource Locks: "I'm claiming this ticket" is a message; conflicts are communicated, not just flagged.
- Decision Capture + Memory: Past decisions become retrievable knowledge for future work.
- Work Graph + Human Oversight: Approval gates attach to task states; blocked work shows why it's blocked.
A framework that treats these as separate plugins misses the point. The agent memory system should know about the work graph. The messaging system should know about resource locks.
This is the "batteries included" vision: not just that the primitives exist, but that they're wired together with sensible defaults.
Primitive 1: Memory
The problem: Agents operate across time. A task started yesterday needs context today. A decision made last week informs work this week. Without persistent, structured memory, every agent invocation starts from zero.
The requirements:
- Working memory is the agent's current context: what it's doing, what it knows about the immediate task, what it's tried so far. This is typically bounded by context windows and conversation state.
- Long-term memory is structured knowledge that persists across sessions. Past decisions, learned facts, project state, user preferences, guardrails. This requires storage, indexing, and retrieval mechanisms.
Batteries-included convention:
- Working memory managed automatically per task/session
- Long-term memory as a structured graph (not just vectors)
- Explicit "learn" and "recall" primitives in agent vocabulary
- Retrieval quality visible and debuggable
Primitive 2: Identity and Messaging
The problem: When agents multiply, they need to communicate. Agent A discovers something Agent B needs. Agent C is blocked waiting for input. Agent D needs human approval before proceeding.
The requirements:
- Addressability: Agents (and humans) need stable identities that can be messaged.
- Asynchrony: Not everything can be synchronous. Agents work at different speeds; humans are slower still.
- History: What was said? When? In what order? Debugging requires a trail.
- Threading: Conversations have context. A reply relates to what came before.
Batteries-included convention:
- Every agent has a stable, addressable identity
- Message passing is the default coordination mechanism (not shared state)
- Full history retained and searchable
- Human operators can read, search, and inject into message streams
Primitive 3: Work Graph
The problem: Real tasks aren't atomic. They decompose into subtasks with dependencies. Some can parallelize; others must sequence. State needs tracking: pending, in-progress, blocked, complete, failed.
The requirements:
- Task representation: What needs doing, with enough context to do it.
- Dependencies: This waits on that. These can run in parallel.
- State tracking: Where are we? What's blocked? What's done?
- Assignment: Who (which agent, or human) owns this task?
Batteries-included convention:
- Explicit task objects with lifecycle states
- Dependency specification (not just lists, but graphs)
- Automatic conflict detection for parallel work
- Visual work-state representation for operators
Primitive 4: Resource Locks
The problem: Parallel agents can collide. Two agents edit the same file. Two agents call an API with rate limits. Two agents try to deploy to the same environment. Without coordination, corruption or thrashing.
The requirements:
- Voluntary reservations: "I intend to work on ticket 3478", claim it before starting.
- Lease semantics: Claims expire. Crashed agents don't hold locks forever.
- Conflict visibility: When collisions happen (or almost happen), someone needs to know.
- Granularity options: File-level, function-level, resource-level.
Batteries-included convention:
- Explicit resource claim/release primitives
- Lease timeouts with configurable defaults
- Conflict detection before collision, not after
- Lock state visible in operator dashboard
Primitive 5: Decision Capture
The problem: Agents make decisions: which approach, which library, which tradeoff. If those decisions aren't captured, they're invisible. When something goes wrong (or needs to change), there's no record of why things are the way they are.
The requirements:
- Reasoning trails: What was considered? What was chosen? Why?
- Version linkage: This decision led to this approval/invoice.
- Searchability: "When did we decide to use fee discount?"
- Shareability: Other agents (and humans) should be able to access the rationale.
Batteries-included convention:
- Automatic decision capture during agent work
- Structured format (not just raw transcripts)
- Bidirectional linking: decision <> artifact
- Indexed for retrieval by future agents and humans
Primitive 6: Human Oversight
The problem: Agents aren't fully autonomous and shouldn't be. Humans need to observe what's happening, intervene when needed, approve consequential actions, and correct mistakes.
The requirements:
- Observation: What are agents doing right now? What have they done?
- Intervention: Pause, redirect, cancel, reprioritize.
- Approval gates: Certain actions require human sign-off before proceeding.
- Correction mechanisms: When agents are wrong, how do we fix it and teach them?
Batteries-included convention:
- Unified dashboard across all primitives
- Configurable approval gates (by action, risk level, domain)
- Intervention actions: pause, resume, cancel, reassign, override
- Full audit trail: what happened, what was the agent state, what did the human do
AI on Rails is the standardized Pit Crew for your agents, providing the tools and protocols necessary for smooth, fast, and reliable operation. A set of conventions, integrated primitives, and opinionated defaults that let teams build agentic systems without reinventing coordination infrastructure. Part III will tease out UX elements for these agentic primitives. Stay tuned!
This article was originally published on LinkedIn. Read it on LinkedIn →