The Art of Instructions: Why Headless Banking Isn't Enough

By Sean Hsieh, Founder & CEO, Runline

Last week’s piece was about defending against AI attackers. This one is about designing for AI users. Same architectural bet, different blast radius.

Teddy Riker, who runs product on Ramp’s MCP server, posted a piece this week that’s worth reading. Ramp’s MCP server has gone from 275 businesses in January to over 2,500 today — a roughly 9× jump in four months — and Teddy spent the piece on what they’ve learned about building for agents instead of for screens. It sparked this article, and one example he gives is the cleanest way I’ve seen anyone explain what’s changing.

Notion’s notion-create-pages MCP tool description includes the instruction: “For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax.”

Result: every agent write through Notion’s MCP nails the formatting. Tables, bullets, italics, lists — perfect, every time. Slack’s MCP doesn’t do this. Slack uses mrkdwn (its own format — single-asterisk bold, <@U123> mentions), not standard Markdown. The MCP tool description doesn’t tell the calling agent that. The result: agents produce Slack messages with literal **asterisks** instead of bold and [user](mailto:...) instead of <@U123>. You spend more time fixing the formatting than you would have spent typing the message.

Both companies shipped MCP servers. One taught the calling agent how to succeed. The other handed it an API and assumed it would figure things out.

The principle worth holding onto: the interface is no longer the screen — it is the set of instructions the calling agent reads at the moment of use. APIs documented in PDFs the developer “should have read” do not survive the agent transition. Interfaces that teach do.

Most credit union executives I talk to think “headless banking” is the finish line. It is the starting block. The destination is teaching agents at the moment of use, and almost nobody’s core can do that yet.

When your interface does not teach the agent, three things happen. The agent gets it wrong, and the member’s agent loses trust in your system. Or the agent’s vendor writes a custom shim for your CU — fragile, coupled, brittle. Or — and this is the one that should keep CU CIOs up at night — the calling agent quietly routes around your CU to a competitor whose interface did teach it.

What this means for credit unions

In Article 5 (“Your Core Processor Is a Time Capsule”) I argued that legacy CU cores were sealed — closed systems where the only way to extract value was to vibe-engineer around the limitations. Most modern cores have programmatic surfaces now. Symitar exposes APIs through SymXchange and PowerOn. CU*Answers has integration paths. Corelation’s KeyStone has REST endpoints. Even older Episys deployments have wrappers. The black-box era of “no API” is over. The teach-the-agent era hasn’t started.

That progress matters. But headless says only this: every capability has a programmatic surface. AI-native says something different: every capability teaches the calling agent how to use it correctly — with the policy, intent, and edge cases baked into the response itself.

I made the case in Article 18 (“Your Agents, Not Ours”) that credit unions need to own their intelligence rather than rent it from vendors who quietly accumulate it on their behalf. One corollary I developed there was that in an agent-driven world, your API is your UX. Salesforce just put real money behind that corollary. Last week at TDX 2026, Salesforce shipped Headless 360 — every capability of the platform exposed as an API, MCP tool, or CLI command. More than 60 new MCP tools and 30 coding skills, available to developers immediately. Salesforce’s bet: in an agentic world, the surface is the product. They’re right about that. They may not be right that exposing it is enough.

There are two flavors of generative UI a CU has to start thinking about now.

Internal (staff-facing). Picture a CSR at one credit union — six tabs open across three vendor systems, hunting through a member’s hardship history. A late car payment. A sudden drop in deposits. Two other CSRs have already left notes. The CSR knows where to look because she has done it a thousand times. In an AI-native model, the interface would assemble that view for the question being asked: pulling current loans, recent contacts, prior workouts, the policy constraints on what she could offer the member, and what other CSRs already tried — generated, not pre-built. The agent would assemble it because the underlying systems told it what was relevant. (At Runline, Joy — our HR Runner — already does this for HR specialists; the same pattern is what we’d build for a member-services Runner.)

External (member-facing, via the member’s own agent). Maria’s personal agent — pre-authorized by her for transfers under a daily threshold — asks the CU’s interface: “Can Maria send $500 to her mom and what limits apply?” An AI-native CU interface returns the answer and the constraints in one response: the daily ACH cap, the new-payee verification policy if mom isn’t a saved recipient, and a hold-and-review rule that triggers above the cap. (If Maria had asked to wire $5,000 instead of ACHing $500, the envelope would also include Travel Rule recordkeeping under 31 CFR 1010.410, which kicks in on funds transfers above $3,000 — a wire-only rule that doesn’t apply to standard ACH.) The calling agent stays inside the policy envelope without bouncing back to Maria for clarification. The member experience: she asked her agent; it handled it.

The technical gap is concrete. Last week, working through a Symitar file-maintenance audit at one credit union we partner with, we found that 9 of 22 SOP critical fields were falsely showing as “missing” — not because the data wasn’t there, but because Symitar’s MNTFLD column is space-padded to 6 characters and our queries weren’t calling trim() before the comparison. There is no agent-facing instruction in any Symitar API or doc that tells the calling system this. Every external integration with Symitar I have seen hits this, and every one I’ve watched fails the test the first time it tries. (This isn’t Symitar-specific — Episys, KeyStone, Fiserv DNA all have analogous undocumented field semantics. Symitar is just the one I have the trace from this week.) That’s what an interface that doesn’t teach looks like in practice.

Why this gets dangerous fast

Zoom out from one space-padded column at one credit union. The same gap shows up at the top of the market.

Salesforce calling Headless 360 a “platform initiative” understates the moment. It is an admission. The team that built one of the most successful UI businesses in the history of enterprise software just publicly accepted that the UI layer is no longer the moat.

They are betting Salesforce’s next decade on every capability of the platform being reachable by an agent. Every CU core vendor in the country is watching that move. The question worth asking next is not “how do we ship MCP tools?” — every vendor will check that box this year. The question is: what do those tools have to teach the calling agent for our customers to win?

Where today’s CU APIs fall short of AI-native:

• APIs expose endpoints, not business intent. “This account type is restricted to members under 21” lives in a policy PDF, not in the API response.
• APIs document fields, not constraints. “MNTFLD must be space-padded to 6; trim before comparing” lives in tribal knowledge or a forum post — never in the schema.
• APIs return data, not policy logic. “A wire over $3,000 triggers Travel Rule recordkeeping” is a workflow the calling system has to know about, not something the API surfaces inline.
• APIs presuppose a developer who’ll write a transformation layer. Agents need the transformation explained at call time, not in a Confluence page they will never read.

In an agentic world, the calling agent shouldn’t have to crawl your developer documentation — and doesn’t have time to. It needs to know, at the moment of the call: what’s allowed, what’s restricted, what’s required, what’s about to break, and what the policy says about the thing it is trying to do.

Imagine the inverse. An AI-native CU interface returns, with the data, the envelope the data lives in.

{
  "balance": 4823.50,
  "account_id": "M-7821-A"
}

The calling agent has everything it needs to do the right thing. It doesn’t need to call your help desk. It doesn’t need to check a Confluence page. It doesn’t need its vendor to write a Symitar shim. It can complete the work and report back to Maria, all inside the policies your CU set.

That is the difference between headless and AI-native. And the difference compounds, every week, as more members route through more agents.

What to do this quarter

The “layer of doing things” — opening accounts, executing transactions, applying for loans, disputing charges, hardship workouts, account servicing — is increasingly going to be done by agents acting on behalf of humans. Humans, members and staff alike, move up the stack: intent, judgment, exception handling, relationships. The parts that need a human, not the parts a machine should have been doing all along.

The CUs that treat AI as a chatbot bolted onto the member portal are already losing the agent’s first call. They just don’t see it yet, because the agent doesn’t tell them why it routed elsewhere. The window I would watch is roughly twelve to twenty-four months — long enough for the leading personal-agent platforms to mature, short enough that the CUs paying attention now will pull ahead before the rest notice the gap.

Three questions to ask your core vendor on Monday.

1. “For each capability you expose via API, do you also expose the policy envelope — limits, constraints, edge cases — in the same response, in machine-readable form?” If the answer is “that’s what the docs are for,” you have your answer.

2. “When a calling agent makes a request your system can’t fulfill, do you tell the agent why, and what would satisfy the request?” The bad pattern is a 400 error. The good pattern is “This transaction would exceed Maria’s daily ACH limit (illustratively $2,500). Daily limits can be raised — here’s how.”

3. “When a member’s personal agent makes its first call to your system and gets nothing useful back, what is your roadmap for being the second call instead of the last?” Not whether you have an MCP server — every vendor will check that box this year. Whether your interface teaches the calling agent enough to come back.

The CUs that build this layer first — internal and external — become the place where members and their agents want to do business. At Runline, this is what we’re heads-down building. Joy reads her HR Playbooks at the moment of use. Dexter reads his file-maintenance Playbooks at the moment of use. Both ship today; neither is a future product. The same instinct that drove Notion to put its Markdown spec inside the tool description is the instinct that has to drive every CU-facing interface in the next decade.

The interface used to be the member’s window into the credit union. Now it’s the agent’s. Build accordingly.