The Conversation Is Not the Workspace

“Why hasn’t this invoice been paid?”

“The invoice exceeds the purchase order by $400. A correction was requested yesterday under the invoice-resolution policy. The supplier hasn’t responded yet.”

Something needed doing, the agent had the evidence and authority to do it, and the work moved forward without waiting for me.

Now I might want to open the invoice, compare it with the purchase order, or see the request that went out. Or I might be satisfied and move on.

Conversation is a way to operate on work. The work needs a persistent place of its own, with visible state, inspectable evidence, and the ability to move within delegated authority.

A lot of AI interfaces start with conversations, messages, and a box to type into. ChatGPT and Claude make an extraordinary range of things approachable that way. I use them every day. But for accounts payable, I want to see what’s moving, what’s waiting, and where a decision is needed.

Tomorrow, that invoice will still be there. Its progress shouldn’t depend on whether I remember to start another conversation.

Delegation within authority

Routine work should move when the evidence, rules, and delegated authority support it.

Let’s look at a plausible accounts payable scenario. A supplier sends an invoice for $5,400 against a $5,000 purchase order. The system detects the mismatch and places a hold under the applicable policy.

The agent checks the supporting documents. There’s no approved amendment accounting for the difference, and no corrected invoice or correction request already on record. The business has authorized routine correction requests in these circumstances. So the agent sends one to the established supplier contact and records what it sent, why, and under which authority.

It hasn’t approved an additional charge or released a payment. It’s taken a permitted step toward resolving the mismatch.

The job that needs doing should shape the interface. Here, the job is keeping invoices moving through an agreed process. Making someone initiate every routine action leaves a lot of the benefit on the table.

Observation and obligation

Show what’s happening separately from what needs a person’s decision.

Some invoices are ready for the next scheduled step. Some are waiting for suppliers. Some have missing information the system is already chasing. Those belong in the overview.

Our invoice reads “Correction requested. Awaiting supplier.” That’s a persistent workflow state with a supporting record I can open. It should survive the conversation that explained it.

Suppose the supplier replies that the extra $400 was verbally agreed with the purchaser. The agent can’t settle that claim from the records. If I’m the purchaser, I get a specific request to confirm or dispute the additional charge, with the supporting material in reach.

The interface should explain why this reached me and what my decision will allow. “Invoice needs attention” isn’t enough.

I should be able to finish that decision list. “Nothing waiting on you” is useful even when plenty of work is still underway. The system keeps going when I close the window.

Shared selection, multiple ways in

Words and clicks should operate on the same selected objects and application state.

I ask, “Which invoices are waiting on suppliers?” Or click that group in the overview. Either way, I arrive at the same work.

I select our invoice and ask, “What have we sent them?” The request opens alongside it. Selecting another invoice changes what “this invoice” means in the conversation too.

That’s shared selection state, familiar from a list and its detail panel, extended to language. The selected record, filters, time boundary, and view belong to the application. Both conversation and direct manipulation use them. If a request remains ambiguous, resolve it before acting on it.

Conversation is especially useful for expressing an intent I don’t have a button for, exploring a vague concern, or asking why. “Are these delays unusual?” may need a short exchange to establish what I mean. Once that’s clear, show me the relevant work. Keep the result available when the exchange ends.

An agent is another user of the system. It needs reliable ways to identify and act on objects too. A human opening an invoice and an agent checking it need to refer to the same underlying record, even if their interfaces differ.

Views follow the question

Choose a useful representation while preserving the user’s sense of place.

A list helps me find invoices. A comparison explains the $400 difference. A timeline shows when the invoice arrived, the hold was placed, and the request went out.

I don’t want a freshly invented interface every time I ask something. Use consistent defaults for different kinds of results, and let me choose another view when it helps.

The working area can change while the supplier, selected invoice, scope, and time boundary remain understandable. Surrounding controls should keep their purpose. Going quiet for a minute shouldn’t close my investigation or return me to an overview.

Evidence has a status

Keep recorded facts, calculations, hypotheses, and action states distinguishable.

The invoice records $5,400. Comparing it with the purchase order gives a $400 difference. “The supplier probably added freight” is a hypothesis until the documents support it. A polished paragraph can make all three sound equally settled.

“Correction requested” needs evidence too. A draft, an attempted send, a successful send, and a supplier acknowledgement are different states.

I should be able to follow the request back to the comparison, the documents checked, and the policy that authorized it. Small, connected pieces of knowledge let the interface bring those together around the invoice. I don’t need a tour of the whole knowledge graph. I need to understand what the agent relied on.

If a connection wasn’t recorded, say so. An unavailable receiving record doesn’t establish that the goods never arrived.

Stable views over moving work

Keep an investigation stable, and check new actions against current state.

While I’m reading the correction request, the supplier might send a revised invoice. The process should respond according to its rules. My open investigation shouldn’t freeze the business.

But silently swapping in the new invoice would change the evidence underneath me. This is the familiar stale-data problem, and the design choice is: preserve the versions I’m examining, notify me of new information, and let me refresh. A live dashboard can update as work changes; an evidence comparison needs continuity.

Keep the version behind the original hold available. Yesterday’s records may explain yesterday’s decision without describing today’s situation.

That stable view doesn’t authorize stale actions. If I request a follow-up after the supplier has already corrected the invoice, the system should check the current state and surface the conflict before sending anything.

Delegation stays inspectable and adjustable

People should be able to inspect the scope of delegated authority and change it through explicit controls.

Somewhere, an authorized person established that the process could send routine correction requests. I want to see which requests, under what conditions, to whom, and with what limits.

Permission to request a correction doesn’t imply permission to accept a new charge, change supplier bank details, or pay an invoice. Each action needs its own basis and authority.

Review and execution need clear steps. Established checks can run without putting a person at every gate. Missing evidence, conflicting instructions, or a step beyond delegated authority may require a decision from someone who can resolve it.

I might pause further follow-ups because I’ve called the supplier. Show what that pause covers, whether anything is already in flight, and what will resume afterward.

The Back button can restore a previous view. It can’t unsend the email. If an action has already happened, correcting it may need a compensating action, such as a follow-up withdrawing the request. That gets its own authority check and record; it doesn’t erase the original.

Where this is going

These principles are shaping how I’m designing RouteKit’s interface, but the questions extend well beyond invoices. Can the system move work forward within its authority? Can I see what it did and why? Does it bring me a decision when it actually needs one? Can I change the delegation without losing the record?

I still want to ask, “Why hasn’t this invoice been paid?” Sometimes the best answer is that the right next step has already been taken, and there’s nothing I need to do.