The Agent Workflow Pattern That's Replacing Dashboards

Something changed in my mental model of how AI agents fit into workflows, and it happened when I stopped thinking about agents as "like a human at a screen" and started thinking about them as "APIs that happen to be conversational."

The framing that clicked: Salesforce's Headless 360 announcement. They flipped the question from "where do I find this in the UI?" to "can the agent reach it programmatically?" That's the shift.

What Headless AI Actually Means

The old model: you open a dashboard, navigate to a record, update a field. The UI is the interface between human and system.

The headless model: an agent reads, writes, and acts across your CRM, your codebase, your database — from any surface. Slack, ChatGPT, a CLI, another agent. The interface is the API. The UI is irrelevant.

For developers building agentic workflows, this means you're not building "an AI that helps users navigate a UI." You're building "an AI that can execute operations across a system programmatically." The difference changes how you design everything.

Why This Matters for How You Build

When I started building with OpenClaw, I thought in terms of tools: "this agent can check my calendar, send a message, run a command." That was the right level of abstraction for a single agent.

But when agents need to coordinate — my agent talking to your agent, agents accessing shared resources, agents running cross-system workflows — you stop thinking about "can this agent call this tool" and start thinking about "what's the interface contract between agents and systems."

This is why MCP matters more than it first appears. It's not just "a way to give agents tools." It's a standardized interface contract. When you have 10,000+ MCP servers deployed (the late 2025 number from Salesforce's data), you have a world where agents from different vendors can collaborate without custom integration work. That's the headless promise — not "agents can use any system" but "agents can use any system through a shared, auditable interface."

The Practical Implication: Build for Programmatic Access First

Here's my mental checklist now when I'm building a new integration:

1. Can an agent call this operation via API without going through a UI?
2. Is there an MCP server that exposes this capability? (Check GitHub's MCP Registry — it's become the reference index.)
3. If not MCP, is there a CLI or webhook that gives the agent equivalent access?
4. What does the agent need to know about this system's state before it can operate on it?

The fourth point is where most agent integrations break down. The agent can technically call the API, but it doesn't know enough about the system's state to call it correctly. This is why context engineering — designing the information architecture around the agent — matters as much as the tool integration itself.

The Headless Pattern in Practice

The pattern I'm using for OpenClaw integrations that need headless access:

1. Start with the API surface — what can be called programmatically? What requires a UI?
2. Find or build the MCP wrapper — if there's no MCP server for the tool, build a simple one. For a REST API, it's often a weekend project.
3. Design the context contract — what state does the agent need to read before it can execute this operation? Put that in the system prompt, not in the tool description.
4. Test headless-first — before I ever open the UI for this system, I verify the agent can complete the operation via API. If it can't, I fix the integration.

This last point is the useful discipline. Most integrations are tested by a human using the UI and then "also" made available to the agent. Headless-first means you catch the integration gaps that make agents unreliable.

---

Salesforce Headless 360 exposes the full platform via APIs and CLI. GitHub's MCP Registry is the reference index for MCP server discovery. When you're evaluating a new tool for agent integration, the first question is: can this be called headlessly?