An agent is a job description

When a team tells me they’re building an agent, the first thing I ask is what its job is.

I usually get an answer about the model, or the interface, or the tone of voice. Those matter, but none of them is the job. Until someone can describe the job plainly, I don’t think the team is ready to design anything.

Where I learned this

At Flow, my team designed an AI chat inside the Neighbor App. It handled maintenance requests, answered common questions and helped residents with everyday services.

The chat window was the easy part. The hard part was deciding what the assistant was responsible for. What could it do on its own? When did it need to hand off to a person? What did it need to know about the building, the lease, the resident? What should it never promise?

Those are the questions you’d ask if you were hiring a person for the role, and none of them is about the interface.

Now I lead an AI-native design team at Luxury Presence, building for real estate professionals, and the same thing holds. The agents that work are the ones where somebody did the unglamorous job of defining the role.

The job nobody wrote down

Most companies have never written down how their own work gets done.

The knowledge lives in people’s heads. A great agent, the human kind, knows which leads to call back first, how to phrase a difficult message, when to push and when to wait. Ask them to explain it and they’ll say it depends.

An AI agent can’t work from “it depends”. Somebody has to go and find out what it depends on. That’s research, and I think it’s the most useful work a designer can do on an agent project.

What a job description contains

When my team starts on an agent, I ask them to write the role before they draw anything. It covers:

• The outcome. What is this agent here to get done, in one sentence a customer would recognize?
• The authority. What can it do without asking? What needs approval?
• The knowledge. What does it need access to in order to do the job properly?
• The limits. What is out of bounds, and what does it do when it reaches the edge?
• The handoff. Who does it pass work to, and what does that person need to know?
• The standard. How would we tell a good day from a bad one?

If the team can’t fill that in, the product isn’t ready to design. If they can, most of the interface decisions become obvious.

Interview it like a hire

I also ask the team to test an agent the way you’d interview a candidate. Give it the hard cases: the upset customer, the request that’s almost in scope, the situation where the right answer is “I don’t know, let me get someone.”

How it behaves at the edges tells you whether people will trust it, and an agent nobody trusts doesn’t get used. A capable agent that occasionally does something surprising gets switched off. A modest one that’s reliable gets handed more work over time.

Where the design work went

People sometimes ask me whether agents mean less work for designers. In my experience the amount of work is the same, but it has moved.

We spend less time arranging screens and more time on things like: how does the agent show what it did, so a person can check it quickly? How does someone correct it? How do they give it more responsibility as they come to trust it? What does it say when it’s unsure?

Those are design problems, and they’re harder and more interesting than a settings page.

What I ask a team for now

I ask for three things before anyone draws a screen.

First, go and watch the job being done by the people who are good at it. Don’t rely on what the process document says.

Second, write the role down in plain language and get the people who do the work to say whether it’s right.

Third, decide what trust looks like on day one and what it should look like in six months, and design the path between them.

A team that does those three things builds agents people keep using.