The Last Interface

Yesterday, I ran a full enrichment in ZoomInfo, the B2B data platform, without opening ZoomInfo.

I had a CSV. I dropped it into Claude. I typed one sentence. An MCP server called ZoomInfo’s API, enriched the file with headcount, revenue, HQ, and funding data, then returned a finished spreadsheet.

Under a minute.

No login.
No dashboard.
No tab switching.
No learning curve.

Once you see that happen, you cannot unsee what it means.

Software is being pulled away from its own interface.

For sixty years, the screen was the front door of software. You opened an app. You learned its layout. You clicked through menus. You filled forms. You moved from tab to tab. The interface told you how the software wanted to be used.

Now something deeper is changing.

The user no longer wants to operate the software.
The user wants to state intent.
The system should figure out the rest.

That shift looks simple from the outside. It feels like chat. It feels like voice. It feels like asking a tool to “just do it.”

But beneath that surface sits the largest change in software since the web.

Because the interface was never just the screen.

An interface is a contract

It is the contract that lets two systems work together when they do not share the same native language.

A user does not speak Python.
A browser does not speak database storage.
A database does not understand vague human intent.
An LLM does not directly execute code, call APIs, save memory, or check whether something is true right now.

So every layer of software needs a contract.

A button is a contract.
A form is a contract.
An HTTP request is a contract.
A REST API is a contract.
A SQL query is a contract.
A JSON object is a contract.
A tool schema is a contract.
An MCP tool call is a contract.
An agent handoff is a contract.

The names change.

The problem stays the same.

Two systems need to work together. They do not understand each other by default. So we design an interface between them.

That is the whole story of software.

And now, for the first time, the interface is moving from navigation to intention.

The old stack was a chain of contracts

The old stack is not really frontend, backend, and database.

It is a chain of interfaces.

The human has intent.
The machine has logic.
So we create UI: text, buttons, forms, lists, charts, screens.

The browser sits on the user’s device.
The server sits somewhere else.
So we create HTTP and APIs.

The server needs to remember state after the user leaves.
So we create databases and SQL.

The product needs to speak to another product.
So we create external APIs.

None of that is really a lesson in “full stack.”

It is a study of how strict systems talk to each other through contracts.

Then LLMs enter the stack.

A large language model is not a normal strict system. It does not behave like a database. It does not return the same row every time. It takes tokens, predicts the next token, and produces text based on patterns, context, and settings.

That makes it powerful.

It also makes it dangerous.

Because a base model can write about an API, but it cannot call that API. It can write SQL, but it cannot query your database. It can mention a calendar, but it cannot check your calendar. It can sound sure without having the right facts.

This is why hallucination is not only a model problem.

It is also an interface problem.

The model is not connected to the source of truth.
No database.
No retrieval system.
No tool.
No memory.
No external check.

So the next interface appears.

Structured output makes language parseable.
Tool calling turns model intent into action.
MCP gives tools and agents a shared contract.
RAG connects the model to evidence.
Memory connects the model to past state.
Agents add a loop, so the system can decide the next step.

Every new concept appears because the old interface cannot solve the next problem.

That is the part most people miss.

AI is not killing interfaces.
AI is forcing us to redesign them at every layer.

Three shifts are now happening at once

The first shift is commerce.

OpenAI launched Instant Checkout in ChatGPT with Stripe and the Agentic Commerce Protocol. U.S. users can buy from Etsy sellers in ChatGPT, and over a million Shopify merchants were listed as coming soon. Stripe also launched Agentic Commerce Suite to help firms sell through AI agents. (OpenAI)

That changes the web funnel.

The user does not search, click a result, land on a site, compare tabs, add to cart, and check out.

The user asks.
The agent compares.
The purchase happens inside the chat.

The website is no longer the only path to demand. The chat can become the store.

The second shift is work.

Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI tools to data sources and systems. MCP gives AI apps a shared way to connect with tools, data, prompts, and context. (Anthropic)

This matters because agents do not want dashboards.

Agents need callable tools.
They need schemas.
They need permissions.
They need logs.
They need stable ways to read and write state.

Databricks now has managed MCP servers tied to Unity Catalog and Mosaic AI, with governance and access control built in. Salesforce said 8,000 customers had signed up to deploy Agentforce by June 2025. (Databricks)

The third shift is discovery.

People are not only searching Google. They are asking ChatGPT, Claude, Perplexity, Gemini, and Copilot what to use.

This is not just SEO with a new label. It changes how demand starts.

If the assistant does not know your product exists, you may never enter the user’s choice set.

If the assistant knows your product, trusts your docs, understands your category, and can call your tools, you become much easier to use.

The old question was: “Can users find us?”

The new question is: “Can agents understand us, trust us, and act through us?”

The screen does not die. It loses its monopoly.

People love saying “AI will kill UI.”

That is too crude.

UI will not die. It will split.

Some interfaces will fade into the background. A lot of back-office software already exists only because humans needed a way to operate a database. Reports, filters, exports, record edits, approval flows, invoice screens, CRM updates, HR workflows. Much of that work can shift from clicking to asking.

A salesperson should not need five tabs to enrich leads, draft outreach, log notes, update a CRM, and create a follow-up task.

A finance person should not need to move through ten screens to check a payment, match an invoice, and flag an exception.

A student should not need to hunt through old links, lecture notes, PDFs, and chat messages to know what to revise next.

In these cases, the product experience becomes the intent, expressed in language, fulfilled by tools.

But some interfaces will become more valuable.

There will still be tools where the screen matters because the act of seeing, shaping, moving, and choosing is the work. Design tools. Music tools. Creative tools. Dashboards where a human needs judgment. Systems where visual state matters.

So the future is not no UI.

The future is a sharper split.

On one side: invisible work, where agents act through tools.
On the other side: high-craft interfaces, where the screen carries judgment, taste, and control.

Between them sits a new field: intelligence design.

Not just how the app looks.
How the system behaves.
What it predicts.
What it asks.
What it hides.
What it logs.
When it acts.
When it waits.
When it asks a human.

UI is no longer only layout.

UI becomes system behavior.

The real blocker is headless software

Here is where the business problem starts.

Most enterprise software was built for humans.

When a person uses Salesforce, SAP, Workday, ServiceNow, or Oracle, they do not see the full system. They see a screen that hides years of data models, business rules, access rules, edge cases, and workflows.

The UI is not just decoration. It encodes what the user can and cannot do.

Now imagine an agent needs to do the same work.

Can it click buttons? Sometimes. But browser automation is brittle.

Can it call an API? Sometimes. But the API may expose only part of what the UI can do.

Can it read the raw database? Usually not. And even if it could, the raw data is not the product. The rules around the data are part of the product.

This is the headless problem.

Human software has screens.
Agent software needs tools.
Enterprise systems have decades of rules trapped behind screens.

“Just expose an API” sounds easy until you realize the UI may be the only complete expression of the workflow.

This is why headless software is not only a tech issue. It is a business issue.

Customers say, “The data is ours.”

Vendors say, “The system logic is ours.”

Agents make that tension sharper.

Because once agents can read, write, and act across systems, the question becomes: who owns the layer where work happens?

The vendor?
The customer?
The AI assistant?
The agent platform?
The firm that owns the memory?

This is where the next fight in software will happen.

MCP helps. It does not solve everything.

MCP is a huge step because it gives AI systems a shared contract for tools and context.

But MCP is not magic.

It does not decide which task matters.
It does not know which workflow to change.
It does not know when a human must approve.
It does not control cost.
It does not fix bad data.
It does not prevent a long agent loop from drifting.
It does not decide what counts as success.

MCP gives the communication contract.

The system designer still owns the work.

That is why the next key layer is not the model.

It is the harness.

The harness is where production lives

A model can reason, draft, classify, plan, and choose tools.

But the harness decides what the model sees. It decides what tools the model can use. It decides what memory gets loaded. It validates tool calls. It checks permissions. It handles retries. It logs actions. It tracks cost. It compresses context. It routes to subagents. It asks for human approval when risk is high.

The model suggests action.

The harness controls action.

This is the difference between a demo and a system.

A demo can work once.
A system must work when the input is messy, the API is slow, the data is wrong, the user is vague, the budget matters, and the output affects real work.

This is also why prompt engineering is too small a frame.

Prompt engineering is what you say to the model.

Context engineering is everything the model sees: instructions, examples, tools, memory, retrieved data, state, and output shape.

Harness engineering is context engineering plus the whole app layer around it: permissions, tools, logs, retries, cost, state, evals, human review, and deployment.

Prompt engineering is a part.
Context engineering is the input craft.
Harness engineering is the production craft.

That is the skill teams now need.

Agents are not chatbots with tools

This is the mistake most people make.

They start with a chatbot. Then they add tool calls. Then they call it an agent.

But an enterprise agent is not a chatbot.

It is a working part of a business process.

The strongest use cases do not sit in open-ended chat. They sit inside real work: contract intake, claims review, support triage, finance ops, onboarding, lead routing, internal search, software maintenance.

The hard part is not getting the model to sound smart.

The hard part is deciding:

What workflow should change?
What systems does the agent touch?
What data does it need?
What can it change?
What must it never change?
Where should a person step in?
How do we know it worked?
How much should each task cost?
Who owns it after launch?

This is why the best way to approach agents is to start with work, not prompting.

Map the workflow first.

What starts it?
What systems does it touch?
What data comes in?
What output matters?
Where do delays happen?
Where do errors happen?
Where does judgment matter?
Where must a human approve?

If you cannot map the work, you cannot automate it well.

Only after that should you build the loop.

Sense.
Plan.
Act.
Observe.
Reflect.

The agent loop is not the whole product. It is the core unit of work. The harness makes that loop safe, useful, and cheap enough to run.

The new scoreboard for software

If you lead a product today, the old product questions still matter.

Is the product useful?
Is it fast?
Is it easy to use?
Does it solve a real pain?
Can the business grow?

But three new questions now matter just as much.

First: can an agent use your product?

Not visit your site. Not read your docs. Use it. Complete the core job end to end through a clean tool contract.

Second: can the agent trust your product?

Are your tools named well? Are schemas clear? Are permissions strict? Are actions logged? Are errors clear? Are rate limits known? Can the agent recover from failure?

Third: can an AI assistant discover your product?

Do your docs explain the category? Do they answer real user questions? Do they expose use cases, limits, pricing, and examples in a way models can parse? Does your product show up when intent appears?

This is the new layer of growth.

Not just SEO.
Not just UX.
Not just API design.

Agent experience.

The product has to work for humans and machines.

A new kind of operator is being born

The next high-value role will sit between product, engineering, ops, and business.

This person will not only write prompts.

They will find workflows where agents can add value. They will map the current process. They will design the better process. They will connect tools. They will shape context. They will define approval points. They will set metrics. They will manage cost. They will run evals. They will own the agent once it goes live.

Call this role whatever you want.

Agent deployer.
AI workflow architect.
Harness engineer.
AI systems operator.

The title matters less than the skill.

This person must understand APIs, tools, memory, permissions, evals, and cost. But they must also understand the business well enough to know which workflow is worth changing.

This is not a pure coding job.

It is not a pure business job.

It is the job of translating work into systems that can act.

That is why training for this work has to change. It is not enough to learn how to make a model reply. You have to learn how to make a system work.

You have to see what happens when context is too wide.
When a tool call fails.
When the wrong record gets pulled.
When memory creates risk.
When costs spike.
When the model chooses the wrong path.
When a workflow needs human review.

Build. Test. Fail. Fix. Repeat.

That is how harness skill forms.

The next lock-in is memory

There is one more layer that people are not taking seriously enough.

Memory.

When an agent works with you for months, it learns your tone, tasks, tools, rules, team habits, approval paths, and edge cases.

In an enterprise, it may learn your SAP setup, your data quality issues, your pricing rules, your customer exceptions, your legal review paths, and your internal shorthand.

That memory becomes valuable.

Not because it is sentimental. Because it reduces future work.

If you delete the agent but lose the memory, you do not just lose a tool. You lose months of fitted context.

So the next strategic question is not only who owns the model.

It is who owns the memory.

The firm?
The user?
The model provider?
The agent platform?
The SaaS vendor?

This matters because the real long-term asset is not just the interface. It is the state behind the interface.

A dashboard can be replaced.
A trained memory is harder to move.

Six months from now

Picture a Monday morning.

A PM opens an assistant and says:

“Pull churned customers from the last quarter, group them by reason, draft three win-back offers, and push the best experiments into HubSpot.”

The assistant does not open five dashboards.

It calls tools.

One tool pulls the customer list.
One tool checks notes.
One tool segments reasons.
One tool drafts offers.
One tool writes the experiment plan.
One tool pushes it into HubSpot.
One tool logs the decision.

The product experience is not the dashboard.

It is the completed task.

Now extend this to a finance team, a legal team, a school, a hospital, a government office, a sales team, a design team, a software team.

The same question appears everywhere:

Which part of the work should stay with the human?
Which part should move to the agent?
Which part needs a tool?
Which part needs memory?
Which part needs proof?
Which part needs approval?

That is the new design space.

The oldest interface returns

There is a strange full circle here.

Before screens, before software, before keyboards, humans used language.

We asked.
We told.
We warned.
We promised.
We planned.
We taught.
We traded.
We remembered.

Language was the first interface for human coordination.

Software forced us to leave that interface and learn its own.

Click here.
Fill this.
Choose from this dropdown.
Read this error.
Export this CSV.
Upload it there.
Copy this field.
Paste it into that system.

For sixty years, humans learned to speak computer.

Now computers are learning to speak human.

But that does not mean we remove all friction. Some friction protects us. Some questions make us think. Some approvals keep us honest. Some interfaces slow us down because speed without judgment is risk.

This is where the topic stops being only technical.

The interface is not only how we use tools.

The interface shapes what we notice, what we choose, what we ignore, and what we become willing to delegate.

A bad interface makes good intent hard to express.

A powerful interface makes weak intent easy to execute.

That is why the last interface is not just chat. It is not just voice. It is not even the agent.

The last interface is the layer between human intent and machine action.

And that layer needs taste, judgment, memory, permission, proof, and restraint.

The AGI question

If AGI arrives, the deepest question may not be: how smart is it?

The deeper question may be:

What interface should stand between a human being and an intelligence that can act on almost any intent?

Should it obey what we say?
Should it infer what we mean?
Should it challenge what we want?
Should it protect us from our worst impulses?
Should it make us more capable, or more dependent?

If the next interface can understand our words, our context, our habits, our fears, our goals, and our hidden patterns, then the real question is no longer whether machines can understand humans.

The real question is whether humans understand themselves well enough to be safely understood by machines.