In the first installment, I wrote about software whose primary user may not be a person.
That raised a practical question I have been circling ever since.
If agents are going to do real work, where exactly will they do it?
I did not set out to answer that in public.
I started drawing a map for a much more ordinary reason.
I had taken on an expanded product line, and I needed to orient myself.
In my day job, I have mapped HR workflows through the employee life cycle and tied them to the labor laws that govern each step.
Then I overlaid personas and industry verticals.
It began as a way to understand the terrain.
It has turned into something I keep coming back to.
Because the same map that tells me where a product team should focus may also tell us where agents can actually help.
What if the opportunity map for agentic AI isn’t a list of use cases, but a map of what people are accountable for?
01
Three layers, and one overlay
The map has three layers.
None of them is new on its own.
What changed for me was seeing them stacked.
| Layer | The question it answers | Example from the employee life cycle |
|---|---|---|
| Workflows | What work happens, and in what order? | Hire, onboard, pay, leave, promote, separate |
| Obligations | What must be true, by when, for whom? | Required notices, reporting deadlines, record retention, policy updates |
| Personas | Who does the work, decides, or is accountable? | HR generalist, payroll specialist, manager, employee, counsel |
Then comes the overlay.
Industry vertical and jurisdiction change the obligations underneath the same workflow.
A hire in one state, in one industry, is not the same hire in another.
The workflow looks identical on a diagram.
The obligations are not.
I had been treating the workflow as the main thing and the law as a note attached to it.
The map turned that around.
The workflow is how the work gets done.
The obligation is why it has to be done at all.
02
Why obligations are the layer that matters
Workflows are easy to automate badly.
You can make a screen faster, or a form shorter, and call it progress.
Obligations are different.
They have deadlines.
They have consequences.
They differ by place, by employer size, by industry, and they change when a legislature or a regulator decides they should.
They also tend to live in someone’s head, a policy binder, or a spreadsheet that one person trusts.
That is exactly the kind of work an agent could help carry.
It is also exactly the kind of work where a confident wrong answer is expensive.
So I find myself asking different questions about each obligation:
Those questions are not about interfaces.
They are about trust, provenance, and consequence.
Which is why I suspect the obligation map is closer to a map of where agents can help than any list of features I could write.
03
Where the systems meet
Here is the part that surprised me.
When I traced a single obligation end to end, it almost never lived in one system.
Take an ordinary event: someone is hired.
The record starts in one place.
The eligibility paperwork is somewhere else.
The state-specific notices come from a third source.
Payroll setup, benefits enrollment, and policy acknowledgment each have their own home.
The obligation spans all of them.
No single system owns it.
So who does?
Today, a person does.
A specialist who knows which system to check, which source to trust, and which deadline is coming.
That person is the integration layer.
They are carrying context between systems that do not talk to each other, and holding the deadline in their head.
I don’t think that disappears.
But it is where I would look first for agents.
Not because the person is doing something trivial.
Because the work sits between systems, and agents are good at moving between systems when they are given the right access and the right limits.
That is also where the interface matters least.
The agent doesn’t need the screen.
It needs the capability behind it, and permission to use it.
04
What an agent may do alone
The map is only half useful until you mark it up.
For each obligation, I have started asking how much an agent should be trusted with.
It connects directly to the last installment’s question about delegated agency, and the answer is rarely the same twice.
| Tier | What the agent does | Fits when |
|---|---|---|
| Alone | Monitors, gathers, flags, and keeps the audit trail | The action is reversible and the source is authoritative |
| With approval | Drafts the change and waits for a person to confirm | The action touches employees, money, or a legal position |
| Never | Surfaces the question and stops | The decision is judgment, and the consequence is the person’s to own |
The tiers are not a feature list.
They are a statement about accountability.
Whoever is accountable for the obligation today stays accountable tomorrow.
The agent changes how the work gets done, not who answers for it.
That is why the persona layer matters as much as the others.
You cannot decide what needs a human checkpoint until you know which human it is.
05
What this does to how we build
There is a second reason I keep drawing this map.
My team is also working out what an AI-assisted software development life cycle should look like.
That sounds like an engineering question.
I think it is partly a product one.
If an AI can help write, test, and review code, the scarce thing is no longer typing speed.
It is knowing what the code must get right.
An obligation map is a very good answer to that.
It says which behavior is non-negotiable, which source is authoritative, which persona is affected, and which vertical changes the answer.
That is context a human or an agent can build against.
It also turns vague requirements into something testable.
Not “handle leave correctly.”
But: for this workflow, in this jurisdiction, for this persona, this must be true by this date, and here is the evidence.
I am not claiming this makes the development process easy.
I am saying the map gives both people and agents a shared picture of what correct means.
And that picture may matter more than any single prompt.
06
What I’m still unsure about
I don’t think this map is finished.
I’m not sure it ever should be.
Obligations change.
Systems change.
What an agent can be trusted with will change fastest of all.
But I would rather hold an unfinished map than a confident list of use cases.
The terrain is changing, and the map is how I’m paying attention to it.
