If you’ve built even a simple AI agent, you’ve likely asked yourself: What are the actual building blocks here? Between the hype and the frameworks, it’s surprisingly hard to find a clear vocabulary for discussing agent architectures.
That’s the gap agentic primitives aim to fill. Just as RESTful APIs gave us a common language for service integration, primitives provide a shared vocabulary for designing, building, and governing AI agents—regardless of which framework or platform you’re using.
Why Primitives Matter
Think of primitives as the atoms of agent architecture. Combine them in different configurations to create anything from simple chatbots to complex multi-agent orchestrations. The value isn’t in the individual pieces—it’s in having a standardized way to think about and communicate system design.
When an architect says “we’re using agentic orchestration with point-to-point connections,” everyone on the team knows what that means. When a governance team asks “which tools have action capabilities,” you can answer precisely. When you’re evaluating frameworks, you can map their concepts to primitives and understand exactly what they support.
The Six Categories
Primitives organize into six fundamental categories, each answering a specific architectural question:
| Category | Purpose | Key Question | Primary Consumer |
|---|---|---|---|
| Actors | Who participates | Who initiates, executes, and consumes work? | Reference |
| Tools | What capabilities exist | What can agents access and do? | LLM + Platform |
| Instructions | How behavior is defined | What guides reasoning, actions, and goals? | LLM |
| Coordination | How work is orchestrated | How is work sequenced and delegated? | Platform |
| Connections | How components link | How do agents reach tools and each other? | Platform |
| Interactions | How communication happens | What flows between participants? | Platform |
Understanding Primary Consumers
Each primitive has a primary consumer—the system component that directly uses it:
- LLM: Consumed by the language model at runtime (instructions, tool descriptions)
- Platform: Configured in orchestration infrastructure (connections, triggers, coordination)
- LLM + Platform: Split between both (tools have LLM descriptions and platform bindings)
- Reference: Documentation/governance layer (actors, traceability)
This distinction matters when building specifications. LLM-consumed primitives need complete prose descriptions. Platform-consumed primitives need structured configuration. Getting this wrong leads to either confused models or brittle infrastructure.
1. Actors: Who Participates
Actors define the participants in your agent system—the entities that initiate, execute, or consume work.
Users
Human participants who interact with and oversee agents. They range from end-users making requests to operators monitoring behavior to administrators configuring permissions.
Examples:
- A customer asking a support agent to check order status
- An analyst requesting a research summary
- An administrator setting guardrails for autonomous processes
Design Considerations: What level of control do users need? When should agents escalate to humans? How do you balance autonomy with oversight?
Agents
Autonomous or semi-autonomous AI entities that perceive, reason, and act toward goals. The core actors that execute work by combining LLM capabilities with tools, knowledge, and instructions.
Examples:
- A customer service agent handling support tickets
- A code review agent analyzing pull requests
- A research agent synthesizing information from multiple sources
Design Considerations: What level of autonomy is appropriate? What specializations make sense? How much memory and context should agents maintain?
2. Tools: What Agents Can Do
Tools extend agent capabilities beyond pure reasoning. They’re the interfaces through which agents access external systems, retrieve information, and take action.
Knowledge Tools
Read-only interfaces that provide agents with information they need to reason and respond. They connect agents to knowledge bases, databases, documents, APIs, and search systems.
Examples:
- Vector search querying a RAG system
- Database queries retrieving customer records
- Web search finding current information
- File readers accessing uploaded documents
- API retrievals making GET requests
Protocol Examples: MCP resources, OpenAI file_search, retrieval tools.
→ Deep dive: What Are Knowledge Tools?
Action Tools
Tools that modify external state, trigger processes, or cause effects in connected systems. They enable agents to create records, send messages, execute code, and update systems.
Examples:
- API mutations (POST/PUT/DELETE)
- Code execution in sandboxed environments
- Email composition and delivery
- Ticket creation in project management systems
- Database writes (insert, update, delete)
Protocol Examples: MCP tools, OpenAI function calling, Anthropic computer use.
Critical Consideration: Action tools require careful governance. Consider idempotency, rollback capability, confirmation requirements, and comprehensive audit logging.
→ Deep dive: What Are Action Tools?
3. Instructions: How Behavior is Defined
Instructions shape how agents interpret requests, reason through problems, and generate responses. They operate at three levels: individual agent, workflow, and system-wide.
Agent Instructions
The core personality, capabilities, and behavioral guidelines for an individual agent. This is the agent’s “constitution” that persists across all interactions.
Example:
“You are a technical support specialist for enterprise software. You have deep knowledge of database administration and can help users troubleshoot performance issues. Always verify customer identity before discussing account details. Escalate to a human agent if the customer expresses frustration three times.”
→ Deep dive: What Are Agent Instructions?
Workflow Instructions
Step-by-step procedures for accomplishing specific tasks or processes. They define sequences, decision points, required inputs/outputs, and success criteria.
Examples:
- Lead qualification: gather info → score against criteria → route to appropriate team
- Incident response: assess severity → notify stakeholders → investigate → document
- Content creation: research → outline → draft → review → publish
Also Known As: Runbooks, playbooks, SOPs (standard operating procedures).
→ Deep dive: What Are Workflow Instructions?
System Instructions
Platform-level rules, constraints, and objectives that govern all agents within an environment. They override agent-specific instructions when conflicts arise.
System instructions have two components:
Constraints (Guardrails):
- “Never share customer PII in logs or external communications”
- “All financial transactions require human approval above $10,000”
- “Agents must not access production databases during business hours without authorization”
Intent (System Goals):
- “Minimize customer wait time while maintaining 95% accuracy”
- “Prioritize security over convenience for all financial operations”
- “Optimize for cost when processing non-urgent batch requests”
Intent helps resolve conflicts between competing priorities and enables more autonomous decision-making.
→ Deep dive: What Are System Instructions?
4. Coordination: How Work is Orchestrated
Coordination primitives determine how work is sequenced, delegated, and synchronized across agents, tools, and workflows. Three fundamental approaches exist.
Workflow Orchestration
Centralized, deterministic coordination that executes predefined sequences of steps. The exact path is known before execution begins, and a central controller directs every step.
Examples:
- Document processing: extract → validate → transform → load
- Approval workflow: submit → review → approve/reject → notify
- Batch processing: query → process → aggregate → report
Characteristics: Predictable, auditable, resumable, version-controlled.
When to Use: When compliance, auditability, or exact reproducibility matter. When the process is well-understood and variations are limited.
→ Deep dive: What Is Workflow Orchestration?
Agentic Orchestration
Centralized, dynamic coordination where an agent uses reasoning to plan and delegate work. A coordinator agent (sometimes called a supervisor or meta-agent) directs the work but can adapt plans based on intermediate results.
Examples:
- A project manager agent breaking down a feature request into tasks for specialist agents (researcher, coder, tester, documenter)
- A customer service router analyzing requests and delegating to appropriate specialists
- A research coordinator planning investigation strategies and tasking multiple retrieval agents
Characteristics: Adaptive, goal-oriented, handles ambiguity, learns from feedback.
When to Use: When tasks are complex, requirements are ambiguous, or the optimal path isn’t known in advance. When flexibility matters more than strict reproducibility.
→ Deep dive: What Is Agentic Orchestration?
Choreography
Decentralized coordination where agents react to events without a central controller. Coordination emerges from the collective behavior of autonomous agents reacting to each other’s outputs.
Examples:
- Order fulfillment where inventory, shipping, and notification agents each react to order events independently
- Content pipeline where agents publish events triggering subsequent agents (research → writing → editing → publishing)
- Monitoring swarm where anomaly detection agents publish alerts that remediation agents independently consume
Characteristics: Loosely coupled, scalable, resilient, no single point of failure.
When to Use: When you need high scalability, resilience, or loose coupling. When agents should operate autonomously without waiting for central direction.
→ Deep dive: What Is Choreography?
5. Connections: How Components Link
Connections are the infrastructure that links actors, tools, and agents. They define how components find and communicate with one another.
Point-to-Point
Direct, explicit connections between two specific components. An agent’s binding to a specific tool, a supervisor’s link to a specialist agent, or a UI hardwired to a conversational agent.
Characteristics: Explicit routing, low overhead, clear ownership, easy to reason about.
When to Use: When you know exactly which components need to communicate. When simplicity and predictability matter more than flexibility.
→ Deep dive: What Are Point-to-Point Connections?
Dynamic (Discovery)
Dynamic lookup of available resources from shared registries or catalogs. Components find capabilities at runtime rather than having them hardwired.
Examples:
- An agent querying a tool registry to find capabilities matching a task
- An orchestrator discovering available specialist agents based on declared expertise
- Tools advertising themselves to an MCP registry
- An API gateway providing a catalog of available services
Characteristics: Loosely coupled, scalable, flexible, supports dynamic composition.
When to Use: When the system needs to evolve without reconfiguring every connection. When you want agents to dynamically select the best available resource.
→ Deep dive: What Are Dynamic Connections?
Queued
Message infrastructure that decouples senders and receivers in time. Producers place messages into queues, and consumers pull them when ready—enabling resilient, asynchronous communication.
Examples:
- Work queue distributing tasks across multiple specialist agents
- Event stream publishing notifications to multiple subscribers
- Integration queue buffering requests to external systems
- Dead letter queue capturing failed processing attempts
Characteristics: Resilient, scalable, buffers load spikes, enables work distribution, guarantees delivery (at various levels).
When to Use: When you need asynchronous processing, load buffering, fault tolerance, or guaranteed delivery. When temporal decoupling matters more than immediate response.
→ Deep dive: What Are Queued Connections?
6. Interactions: How Communication Happens
Interactions define how information flows between actors—the communication patterns that enable coordination and collaboration.
Messages
Discrete units of communication between actors. They come in three fundamental types:
Delegation (Command): Instructions requesting specific action.
- “Summarize the attached document”
- “Create a Jira ticket for this bug report”
→ Deep dive: What Is Delegation?
Retrieval (Query): Requests for information without requiring action.
- “What’s the status of order #12345?”
- “How many open support tickets are there?”
→ Deep dive: What Is Retrieval?
Notification (Event): Announcements about state changes or occurrences.
- “New customer signed up”
- “Payment processed successfully”
- “Document review completed”
→ Deep dive: What Is Notification?
Conversations
Sustained, contextual exchanges between actors over multiple turns. They maintain context across messages, enabling nuanced interaction that builds on previous exchanges.
Examples:
- A troubleshooting session with iterative clarifying questions
- A negotiation between agents to resolve conflicting resource requests
- Collaborative document creation with iterative refinement
Components: Thread (conversation container), Turns (individual exchanges), Memory (retained information), State (current status and pending actions).
→ Deep dive: What Are Conversations?
Composition Patterns
Primitives combine into recognizable patterns for common use cases:
Simple Assistant:
User → Agent → [Knowledge Tools]
A single agent with retrieval capabilities answering questions.
Autonomous Worker:
Event → Agent → [Action Tools] → Event
An agent triggered by events that takes action and publishes results.
Supervised Delegation:
User → Agent (orchestrator) → [Specialist Agents] → [Tools]
A coordinator agent breaking down complex requests across specialists.
Pipeline Processing:
Event → Workflow → Agent₁ → Agent₂ → Agent₃ → Output
Deterministic flow passing work through specialized agents in sequence.
Event-Driven Swarm:
System Intent → Event Stream ↔ [Autonomous Agents] → Output
Multiple agents independently reacting to events and each other’s outputs.
Design Principles
When working with agentic primitives, keep these principles in mind:
Start Simple: Begin with the minimum primitives needed. Add complexity only when requirements demand it.
Explicit Over Implicit: Make connections, permissions, and instructions visible and auditable.
Composability: Design primitives to combine cleanly. Avoid tight coupling that prevents reconfiguration.
Governance by Default: Build guardrails into the architecture, not as afterthoughts.
Observability: Ensure every primitive interaction can be logged, traced, and analyzed.
Putting It Into Practice
The value of primitives isn’t in memorizing definitions—it’s in using them as a design language. When architecting a new agent system:
- Start with actors: Who will use this? What agents do you need?
- Define capabilities: What tools do agents need to accomplish their goals?
- Establish guardrails: What system instructions constrain behavior?
- Choose coordination: Does the problem call for workflows, agentic orchestration, or choreography?
- Design interactions: How will components communicate?
- Plan connections: Point-to-point for simplicity, discovery for flexibility.
These primitives provide a foundation for discussing, designing, and building AI agent systems with clarity and consistency. As the field evolves, expect new primitives to emerge—but the core categories of actors, tools, instructions, coordination, connections, and interactions will remain fundamental.
Want to dive deeper into agent architecture? Check out the AI Agent Canvas for a complete design framework, or explore coordination patterns for detailed implementation guidance.