Choosing the Right Building Block
Fifteen building blocks, four layers — but which ones does your workflow actually need? This page gives you comparison tables to quickly differentiate the blocks and a decision guide to match your situation to the right starting point.
Most workflows need just two or three blocks. The goal isn’t to use them all — it’s to pick the right ones for the job.
At a Glance
Section titled “At a Glance”All blocks in one view — use this to quickly orient yourself, then drill into the layer tables below for full details.
| Block | Primary Job | Best For | Typical User |
|---|---|---|---|
| Model | Process and generate | Choosing the right engine for speed, depth, or cost | Everyone |
| Context | Inform | Grounding the model in your specific domain knowledge | Everyone |
| Project | Organize | Persisting instructions and context across conversations | Everyone |
| Memory | Remember | Accumulating preferences and patterns over time | Everyone |
| Prompt | Instruct | One-off or conversational tasks with clear instructions | Everyone |
| Skill | Standardize | Repeatable routines you run the same way every time | Everyone |
| Agent | Execute autonomously | Multi-step workflows requiring planning and tool use | Power user |
| MCP | Connect | Bridging AI to external tools, data, and services | Power user |
| API | Integrate programmatically | Embedding AI in applications and automated pipelines | Developer |
| SDK | Orchestrate in code | Building agent systems with tool use, memory, and handoffs | Developer |
| CLI | Interact from terminal | Working with AI in the terminal, scripting, and headless automation | Power user / Developer |
| Harness | Run the agent | Choosing the app or tool that gives a model its tools, memory, and loop | Everyone |
| Registry | Catalog | Knowing every AI workflow you run, what it serves, and what it uses | Everyone |
| Observability | Make visible | Seeing what an AI system did on each run, and why | Power user / Developer |
| Evaluation | Measure quality | Checking output is accurate, safe, and good enough, before and after every change | Everyone |
Intelligence Layer
Section titled “Intelligence Layer”The persistent foundation: engine, knowledge, and workspace powering every interaction.
| Model | Context | Project | Memory | |
|---|---|---|---|---|
| What it provides | AI engine that processes inputs and generates outputs | Background knowledge the model doesn’t have | Persistent workspace grouping instructions, context, and skills | Accumulated knowledge from past interactions |
| Primary job | Process and generate | Inform | Organize | Remember |
| Persistence | Always available (platform-managed) | Ephemeral (per-conversation) or attached to a project | Persistent across conversations | Persistent and growing across conversations |
| Contains | Trained weights, capability tiers, modality support | Files, docs, data, examples, reference material | Instructions, context files, conversation history, skills | Preferences, decisions, facts, learned patterns |
| When it loads | Selected before or during a conversation | Attached at conversation start or mid-conversation | Active when you open a conversation in the project | Retrieved automatically when relevant |
| Can include code | No (model selection, not authoring) | Yes (code files as reference material) | Yes (code in project knowledge or instructions) | No (system-managed, natural language) |
| Best for | Choosing the right engine for speed, depth, or cost | Grounding the model in your specific domain | Persisting setup so you don’t re-upload every time | Adapting AI behavior over time without manual setup |
| Who manages it | Platform (you choose tier) | User-curated | User-curated | System-managed |
| Requires external access | No | No (you bring the files) | No | No |
| Typical user | Everyone | Everyone | Everyone | Everyone |
Orchestration Layer
Section titled “Orchestration Layer”The execution layer: instructions, routines, and autonomous agents that direct and do the work.
| Prompt | Skill | Agent | Harness | |
|---|---|---|---|---|
| What it provides | Natural language instructions to the model | Reusable routine with defined inputs and outputs | Autonomous AI that plans, uses tools, and executes multi-step work | The software around a model that turns it into a working agent |
| Primary job | Instruct | Standardize | Execute autonomously | Run the agent |
| Persistence | Ephemeral (per-conversation) | Persistent (saved as files, reusable across conversations) | Ephemeral (runs for a session) or scheduled | Persistent (the app or tool you work in) |
| Contains | Natural language instructions, examples, constraints | Instructions, reference files, output format specs | Goals, tool access, planning logic, decision-making | The agent loop, tool access, permissions, memory handling |
| When it loads | When you type or send a message | Auto-triggered when relevant, or invoked via slash command | Launched explicitly or on a schedule | Always running whenever you use an AI app or agent |
| Can include code | No (natural language only) | Yes (scripts, templates, code references) | Yes (reads, writes, and runs code) | Yes (built from code; SDKs let you build your own) |
| Best for | One-off or conversational tasks with clear instructions | Repeatable routines you run the same way every time | Multi-step workflows requiring planning and tool use | Matching the app or tool to the kind of work |
| Who manages it | User (typed in the moment) | User-curated (packaged for reuse) | User-launched or developer-built | Platform-provided or developer-built |
| Requires external access | No | No (self-contained instructions) | Often yes (uses tools, files, MCP connections) | Often yes (supplies the tools and connections) |
| Typical user | Everyone | Everyone | Power user | Everyone |
Integration Layer
Section titled “Integration Layer”The connection layer: protocols, interfaces, and frameworks that bridge AI to external systems and code.
| MCP | API | SDK | CLI | |
|---|---|---|---|---|
| What it provides | Connector to external tools, services, and databases | Programmatic interface for accessing AI models | Frameworks for building AI workflows in code | Terminal-native interface for interacting with AI |
| Primary job | Connect | Integrate programmatically | Orchestrate in code | Interact from terminal |
| Persistence | Persistent (configured once, available across conversations) | Stateless (each call is independent) | Persistent (code you deploy and maintain) | Persistent (project memory files, settings) |
| Contains | Server configs, tool definitions, authentication | API keys, endpoint URLs, request/response schemas | Libraries, agent loops, tool abstractions, patterns | Skills, plugins, hooks, MCP connections, project memory |
| When it loads | Connected at startup or configured in settings | Called on demand from code | Imported into your application code | Launched from the terminal interactively or via script |
| Can include code | Yes (server implementations) | Yes (code making HTTP requests) | Yes (the primary interface is code) | Yes (reads, writes, and runs code) |
| Best for | Bridging AI to external tools, data, and services | Embedding AI in applications and automated pipelines | Building agent systems with tool use, memory, and handoffs | Working with AI in the terminal, scripting, headless automation |
| Who manages it | User-configured or developer-built | Developer-owned | Developer-owned | User-launched or script-driven |
| Requires external access | Yes (bridges to external systems) | Yes (calls external APIs) | Yes (wraps APIs and external services) | Yes (calls APIs under the hood) |
| Typical user | Power user | Developer | Developer | Power user / Developer |
Governance Layer
Section titled “Governance Layer”The guardrail layer: catalogs, visibility, and measurement that keep AI work accountable and trustworthy.
| Registry | Observability | Evaluation | |
|---|---|---|---|
| What it provides | Catalog of every AI workflow, the process it serves, and the blocks it uses | Visibility into what an AI system did, why, and how well | Repeatable measurement of whether output is accurate, safe, and good enough |
| Primary job | Catalog | Make visible | Measure quality |
| Persistence | Persistent (files you own, updated as workflows change) | Persistent (metrics, traces, and logs kept over time) | Persistent (test cases and criteria reused on every run) |
| Contains | Workflow records, process links, skill and agent references | Metrics, traces, logs | Test cases, yes/no criteria, AI or human grader results |
| When it loads | Read when you plan, build, or change a workflow | Collected during every run | Run before you rely on a workflow, after every change, and periodically |
| Can include code | Optional (lint and compose scripts) | Yes (instrumentation, dashboards) | Yes (automated test runs and graders) |
| Best for | Knowing what you have, who owns it, and what it depends on | Finding out why a run went wrong | Catching quality drops before others notice them |
| Who manages it | User-curated | Platform-provided or developer-configured | User-defined criteria, run by person, script, or AI grader |
| Requires external access | No | Often yes (platform consoles, logging services) | No (can run on saved inputs) |
| Typical user | Everyone | Power user / Developer | Everyone |
Decision Guide: “I want to…”
Section titled “Decision Guide: “I want to…””Use this table to find your starting point. Most real workflows combine several blocks — this tells you where to begin.
| I want to… | Start with | Add when needed |
|---|---|---|
| Ask AI a question | Prompt | + Context if it needs your specific data |
| Get better answers about my domain | Context + Prompt | + Project to persist the setup |
| Stop re-uploading the same files | Project | + Memory to also retain learned preferences |
| Have AI remember how I like things done | Memory | Already persistent — just keep using it |
| Run the same workflow every week | Skill | + MCP if the skill needs external data |
| Pull live data into a conversation | MCP | + Skill to standardize what you do with the data |
| Automate a multi-step research task | Agent | + MCP for external sources, + Skill for sub-routines |
| Build AI into my app | API | + SDK for complex orchestration |
| Coordinate multiple agents in code | SDK | + MCP for external tool access |
| Work with AI in my terminal | CLI | + Skills for reusable routines, + MCP for external data |
| Automate AI in shell scripts or CI | CLI (headless mode) | + MCP for external system access |
| Get AI help while coding | CLI | + Project memory for persistent conventions |
| Choose between fast and deep AI | Model (select the right tier) | All other blocks work with any model |
| Pick where to run an agent | Harness (the app or tool that fits the work) | + SDK to build your own |
| Keep track of all my AI workflows | Registry | + Evaluation for the ones you rely on |
| Know whether an AI workflow is still good enough | Evaluation | + Observability to see what changed on real runs |
| Find out why an agent went wrong | Observability (read the trace) | + Evaluation to confirm the fix |
Related
Section titled “Related”- Building Blocks Overview — what each block is, with cross-platform implementations
- Design Your AI Workflow — mapping workflow steps to building blocks
- AI Workflow Framework — the full Analyze → Deconstruct → Build methodology