The Intent Interface

At the RAISE Summit in Paris in July 2025, Eric Schmidt described what he called the Universal Interface. His argument was straightforward: for most of computing history, humans had to learn the machine's language. SQL to query a database. Spreadsheet formulas to analyze data. Command line syntax to automate tasks. The machine set the terms, and humans adapted.

That's changing. Language, natural human language, is becoming the universal interface to AI. You describe what you want, and the system figures out how to do it. Schmidt's example was building a house: one agent finds the lot, another checks the regulations, another designs the building, another selects the contractor. All of them coordinating through language, without the human needing to understand how any individual piece works.

It's a compelling idea. I want to extend it.

The problem Schmidt's framing doesn't fully address

Schmidt focuses on language as the input layer. What you say becomes what the system does. That shift is real and it's already here. But there's a second shift happening in parallel that gets far less attention: what happens to the output layer, the place where work actually gets done.

Right now, a typical knowledge worker operates across a dozen tools simultaneously. Project management in Jira or Linear. Documentation in Confluence or Notion. Communication in Slack or Teams. Code in GitHub. Calendar in Google Calendar. Each tool has its own interface, its own notification system, its own way of storing context. Switching between them costs attention. Context gets lost at every boundary. The work of staying synchronized across all of them is itself a form of overhead that never appears on any task list.

Schmidt's Universal Interface changes how you give instructions. What I'm describing changes where you give them, and where everything happens as a result.

The Intent Interface

I call this the Intent Interface. One interface. Not a dashboard that shows you all your tools at once, but a single point of intent: you describe what you want to happen, and the interface figures out which tools need to be involved and coordinates them on your behalf.

"Schedule a review meeting for next Tuesday, create a Jira ticket for the open action points from our last call, and update the Confluence page with the decision we made about the API." One instruction. Executed across three tools. No tab switching, no copy-pasting between systems, no manual synchronization.

This is already technically possible. The connective tissue is an integration layer that gives AI systems a standardized way to read from and write to external tools, whether that's Jira, Confluence, GitHub, Google Calendar, or anything else. MCP, the Model Context Protocol, is one protocol that does exactly this today. The AI doesn't care which tool you're using. It speaks to all of them through the same layer. Claude Desktop is an early version of what this looks like in practice: one interface, and behind it, all the tools your team depends on, connected and coordinated.

Shared memory, shared brain

What makes the Intent Interface more than a convenience feature is the memory layer underneath it. Each tool you currently use holds a fragment of your team's context. Jira knows what tickets exist. Confluence knows what was documented. Slack knows what was discussed. GitHub knows what was built. But none of them know what the others know. You, the human, are currently the integration layer. You carry the context between systems in your head, and you pay the cost every time you switch.

An Intent Interface with shared memory changes this fundamentally. The AI that helps you draft a Jira ticket has read the meeting notes from this morning. The AI that answers a product question has access to the architectural decisions made six months ago. The AI that helps onboard a new team member can surface relevant decisions, documented principles, and historical context without anyone having to remember where it's stored.

This is what a shared brain means in practice. Not a metaphor. A literal shared context layer that connects the information across all the places it currently lives in isolation.

What this means for how teams build

When you take the Intent Interface seriously as a design principle, it changes how you think about tooling decisions entirely. The old question was "which tool should the whole company use?" The new question is "which tools serve each team best, and how do we connect them at the AI layer?"

A product team on Linear, an engineering team on GitHub Issues, an operations team on Motion. Three tools, three workflows, one Intent Interface connecting them. It doesn't require everyone to use the same tool. It requires everyone to be reachable through the same integration layer. The protocol handles that.

This also changes what it means to switch tools. If your workflows are built on top of an Intent Interface layer rather than on top of any specific tool, the migration cost drops to almost nothing. The interface stays the same. The tool underneath it changes. Your team barely notices.

Schmidt's idea, extended

Schmidt described language as the universal interface to AI. That's true, and it matters. The extension I'm proposing is this: language is the input, an integration layer connecting your tools is the connective tissue, and the result is a unified Intent Interface that controls everything behind it from a single point. MCP is one way to build that layer today. Others will follow.

You don't switch tabs anymore. You don't copy context between systems. You don't maintain synchronization manually. You describe what you want, once, and the Intent Interface handles the rest across every tool your team depends on.

That's not a productivity improvement. It's a structural change in how knowledge work gets done. And the teams that build toward it now, deliberately, with connected infrastructure and AI-first workflows, will have a significant advantage over those still managing a dozen open tabs when the shift becomes obvious to everyone.

What this looks like in practice

Over the past few weeks I've built my own version of this. Not as a prototype, as my actual daily infrastructure. More than fifteen self-built tools, all connected through a shared communication pipeline. My health data, calendar entries, meetings, a home renovation project, my business, a coaching academy, and yes, writing these blog posts. All of it happens through a single Intent Interface. Claude.

I don't open an IDE to write code. I don't open a calendar app to manage my schedule. Programming tasks get created as tickets in the background and processed by a local conductor that runs autonomously. QA workers start on their own. Reminders get set. Calendar entries get created and updated. My email inbox gets handled. All of it through writing or speaking to one interface.

Fifteen tools. One conversation.

That's what the Intent Interface looks like when it's actually built. And the surprising thing isn't that it works. It's how quickly everything else starts to feel unnecessary once it does.

What's coming next

This post introduces the concept. The next posts in this series go into the specifics: how to connect your first tools, how to build a shared memory layer that actually works, how to set up an autonomous conductor that processes tasks in the background, and how to avoid the mistakes that make these setups brittle instead of reliable.

If you want to go deeper now rather than waiting for the next post, this is exactly what I cover in my coaching academy. Not theory. Step-by-step implementation for your specific context, whether you're a CTO building this for a team or an individual who wants to run their entire work life through a single interface.

The concepts in this article are freely available here. The implementation is where most people get stuck, and that's where I can help directly.

How many of the tools your team uses could already be connected through a single Intent Interface? And what would you do with the attention you'd get back?