When your users aren't only human

Using Dot lately (swap in Muse or any of the other Personal AI Agents here), I started thinking about a question I’d rarely taken seriously before:

If a lot of things get handed to a Personal Agent first, will software’s users still only be human?

Take Roleward, the job-search tool I built.

Right now, using it looks like this:

• I open Roleward (if I’m using the site rather than the skill);
• search for jobs;
• look at the match analysis;
• save roles;
• update application statuses.

But if I someday have a job-search Dot that knows me over the long run, I probably won’t want to open Roleward every day anymore.

I’d just ask:

How’s the job search going? Anything I need to deal with?

Then Dot would go read Roleward’s state, search for new roles, check Gmail, and bring back only the things that actually need my judgment.

Which raises the question:

How does Dot use Roleward?

That question also finally gave me a practical grip on MCP, Tool, Signal—all the concepts that have been so hot lately.

01 Not every product needs to be an Agent

With Agents this hot, it’s easy to have a knee-jerk reaction:

Should my product build an Agent too?

But Roleward has no reason to become another Dot.

Dot can handle:

• understanding my long-term goals;
• deciding what to do right now;
• coordinating different tools;
• coming back to me on its own when needed.

Roleward is better suited to something else:

• letting an Agent like that use it well.

That’s how I now understand the difference between an Agent and being Agent-ready.

An Agent has its own goals and keeps acting on them.

An Agent-ready product doesn’t necessarily have an Agent of its own; its core capabilities can be called safely and clearly by outside Agents.

02 If Dot is going to get into Roleward, it needs a door

Say Dot wants to do a few things:

• read my job-search pipeline;
• save a new role;
• look at the match analysis for a role;
• update an application status.

Roleward needs to offer those capabilities, for example:

• get_pipeline()
• save_job()
• evaluate_job()
• update_application()

These are the Tools an Agent can call.

But how does Dot know Roleward has these Tools?

What parameters does each Tool take?

What does it return?

What permissions does it need?

What does it mean when it fails?

This is where MCP comes in.

You can roughly picture the relationship like this:

Dot / ChatGPT↓MCP client↓MCP↓Roleward MCP server↓Roleward backend / database

MCP is a set of communication rules both sides agree to follow.

The ChatGPT side is the MCP client;

if Roleward wants to support this kind of call, it can provide an MCP server.

And an MCP server isn’t necessarily some huge “server.”

Here, “server” is closer to a role:

it’s responsible for exposing what Roleward can offer an Agent, according to the MCP standard.

For example, telling the Agent:

• I have a save_job Tool;
• here’s when it makes sense to use it;
• it needs a title, company and URL;
• on success it returns a job ID;
• this Tool modifies user data, so it needs the corresponding permission.

03 So how do API and MCP relate?

Roleward may already have an API of its own.

The web frontend needs to read data, save roles and call AI services, so it’s already talking to the backend.

An API answers:

how software calls Roleward.

MCP leans more toward:

how an Agent discovers, understands and calls those capabilities.

A lot of the time, the MCP server is still calling the existing API underneath.

So it’s not either/or.

You can think of it like this:

Agent↓MCP Tool↓Roleward API↓the real data and business logic

That’s also why I find MCP interesting now.

It isn’t yet another invention to “make AI smarter.”

It solves a very practical problem:

once the model understands what the user wants, how does it actually get into the real world of software and get the thing done?

04 But “able to act” isn’t enough—the Agent also needs to know when to act

This is something I only really felt after creating my own job-search Dot.

I’d assumed:

since it’s an always-on agent, it should keep looking for new roles on its own.

But when I actually set up the task, I still had to tell it:

check once a day.

The reason is simple.

However smart an Agent is, it still needs a signal telling it:

something in the real world may have changed.

A signal could be:

• 9 a.m. every day;
• a new recruiter email arriving;
• an application status update;
• a role with no progress for seven days;
• CI test failed;
• a metric crossing a threshold;
• the user just uploading a file.

Only after receiving a signal does the Agent re-evaluate:

• Does this matter?
• Does it need action now?
• Which Tool should it call?
• Does it need to check with a human?

So I now take Signal a lot more seriously than I used to.

If a product wants to be used by an always-on Agent, it doesn’t just have to answer:

What can the Agent do?

It also has to answer:

What changes should the Agent find out about?

05 An Agent isn’t quite the same as a regular user

There’s another thing I rarely thought about before: permissions.

If Dot updates an application status in Roleward for me, the system should ideally know:

this is Dot acting on behalf of Limin.

An Agent is more like a delegated actor.

So the product has to start thinking about:

• What can it read?
• Can it write?
• Which actions need human approval?
• Who authorized this Agent?
• When does that authorization expire?
• Can mistakes be undone?
• Looking back later, can you tell who actually did what?

The more capable Agents get, the more these things—once easy to file away as backend engineering—become part of the product experience.

06 So will SaaS UIs disappear?

I think this question needs to be broken apart.

Say in the future I almost never open Roleward.

Roleward still needs to store:

• roles;
• application state;
• scoring;
• user data;
• all kinds of business logic.

What might shrink is just:

• the need for the user to go into the UI personally and work through those capabilities step by step.

So the same product may end up with two entry points:

Human → UI

Agent → Tools / API / MCP

The UI is still good for browsing, comparing, checking and making complex judgments.

Agents are better at executing, coordinating and following up over time.

The exact balance depends on the product.

So I’m not going to MCP-ify all my products just because MCP is hot right now.

A product that mainly processes private data locally, for instance, or a tool that only works after the user explicitly uploads something, doesn’t necessarily need an always-on Agent or a remote MCP.

Have a real Agent use case first, then decide whether to be Agent-ready.

That’s the order I’m sticking to now.

07 If Agents might become your product’s users too

These days I ask three extra questions:

First, what are my product’s core capabilities that are genuinely worth calling?

Don’t turn every button in the UI into a Tool.

What you expose should be:

save_job

not:

click_save_button

Second, how does the Agent know something in the real world has changed?

Is there an event, webhook, notification, state change or some other signal?

Third, are these calls safe, verifiable and traceable?

How do you design permissions, approval, audit and undo?

For me, right now, these three questions are more worth answering first than:

“Should my product build an Agent too?”

Because if Personal Agents really do become more and more users’ entry point, we may not all need to build yet another Agent.

But more and more software may need to be ready to be used by Agents.