When Software Becomes the User

At six in the morning, a reporting worker wakes up on a schedule that nobody has thought about since the day it was written, connects to an MCP server, discovers the capability it needs, and has the numbers sitting in a channel before the first laptop opens.

There is no chat window anywhere in that story, no dashboard, no consent screen, and no person watching a spinner resolve. The entire thing happens inside the hours we quietly assume software spends idle, and the reason it is worth writing about is not that it looks impressive but that it looks like nothing at all.

The first wave kept the human trigger

For most people the MCP story still begins with a person talking to an assistant. You ask Claude or ChatGPT for something, it discovers a tool, and software on the other side does the work you would otherwise have done by clicking through a product's screens yourself. I do not want to undersell that, because being able to express an outcome instead of navigating an interface is the most meaningful change to how people reach software in a decade.

But it moved the interface without moving the trigger, and the trigger is where the actual constraint has always been sitting.

I have been arguing for a while now that businesses are separating into two shapes, the ones that remain destinations you go to and the ones that become capabilities agents route through, and unattended calling is where that distinction stops being a thesis and starts being an architecture decision. A capability that only ever fires when a human types a sentence is still a destination with a protocol bolted to the front of it. The screen was replaced by a prompt, and the waiting survived the upgrade intact.

The next user of software is software

Once a workload can authenticate as itself, rather than borrowing a person's session and impersonating them for the duration of a job, there is no longer any reason for the client to be a chat window. It can be a clock that fires at five, a queue that fills up when something goes wrong at three in the morning, a pipeline holding a release until a check comes back clean, or another product that needs a governed action performed on its behalf.

What that unlocks is a set of patterns that used to arrive as custom integration work, scoped separately and staffed separately every single time:

• A scheduled worker assembles the morning operations report from live systems, so the meeting starts with the numbers already on the table.
• A backend agent begins investigating an account the moment a risk event lands on a queue, rather than the moment somebody notices it in a weekly review.
• A synchronization service reconciles records between two products continuously, instead of in the quarterly cleanup nobody volunteers for.
• A CI pipeline calls a validation capability and refuses to promote the build until it answers.
• One service asks another to perform a business action through exactly the same MCP surface an assistant would have used, with the same permissions and the same audit trail.

Those are not five integrations. They are five clients pointed at one capability layer, which is a materially different line item on an engineering roadmap.

The product keeps working between conversations

Take a customer success platform, which is a category that lives or dies on noticing things early.

In the interactive version, an account manager asks an assistant which renewals look shaky this week, and the assistant calls the platform's tools, pulls the usage and sentiment signals, and comes back with an answer that is genuinely useful to the person who thought to ask for it.

In the unattended version, nobody asks. A worker checks the same signals every morning before the team logs in, and an event-driven agent starts digging the moment a strategic account's usage falls off a cliff, which is usually somewhere around a Saturday night when the discovery would otherwise have waited until Monday.

The capability did not change between those two versions. Only the trigger did, and with it the entire question of whether the product is something you consult or something that is looking out for you.

That is a more interesting question for a software company than whether it has shipped an AI feature this quarter. The one worth arguing about internally is which parts of your product should keep working when there is nobody looking at the screen.

From endpoints to capabilities

None of the machine to machine part is new, and it would be dishonest to pretend otherwise. Webhooks, queues and cron jobs have been running most of the world's software quietly for decades, largely without credit.

What MCP contributes is a capability surface that a client can discover rather than reverse engineer. Historically every agent integration began with an engineer reading your documentation and building a private map of your endpoints, a map that broke the moment you shipped anything, whereas now a client that speaks the protocol can ask what you expose and call it without any prior relationship with your team.

That does not replace your API, and your business system remains the source of truth for everything that matters. What it changes is legibility, because the actions your product can perform become readable to clients you have never met and did not design for.

The size of that payoff depends almost entirely on where you draw the capability boundary. A tool called generate_report is worth more to a caller than the pile of table endpoints underneath it, and investigate_renewal_risk tells a client what outcome it is allowed to ask for rather than making it assemble that outcome from parts. Draw the boundary at the level of the work instead of the level of the schema, and the product ends up participating in places you never built for.

Every workload gets its own identity

The security rule underneath all of this is short enough to fit in a sentence, which is that unattended software should never be pretending to be a person.

A reporting worker deserves an identity of its own, scoped to the exact application, environment and permissions it actually needs, holding a short-lived token bound to the deployed MCP resource, with a credential that rotates on a schedule and access that can be revoked on its own without taking down every other client you happen to be running. Handled that way, background automation stops being a thing security has to say no to, because there is no shared employee login involved, no single omnipotent secret circulating through config files, and no pretense that a CI job and a finance agent belong at the same trust level.

We shipped this in Noodle Seed as an OAuth Client Credentials extension, currently in Preview, so you can create an organization-owned service principal, grant it access to a single deployment target, and authenticate with either a public key or a client secret. Your application code stays exactly as it is, and nothing needs to be redeployed for it to work.

Software does not have to wait for us

The first era of agent-connected software was about being reachable inside a conversation, and that still matters, because people should be able to get to your product from wherever they happen to be expressing intent rather than from wherever you decided to put your navigation.

What changes now is that the same capability becomes reachable outside the conversation too, by a clock, an event, a pipeline, or another piece of software acting on a schedule nobody has to remember. Products can prepare, validate, reconcile and respond in the long gaps between moments of human attention, which is where most of the useful work has always been hiding anyway.

I want to be careful about what this is not, because it is not an argument for removing people from decisions that deserve them. It is an argument against requiring a person to manually start every process that was going to be necessary regardless.

When software becomes the user, MCP stops being the way people talk to your systems and becomes part of the way your systems run.