Stop Operating Software. Start Managing It.

Your next software interface may look less like a dashboard and more like a work order. You describe the outcome, attach the relevant context, set limits, and receive something to review. The shift is from operating each step yourself to managing a system that plans and executes several steps on your behalf.

Chat alone changes very little. A faster way to ask for a first draft is pleasant, but it still leaves you driving every turn. Agentic workflows change the shape of the job: they search, call tools, inspect their own work, retry, and return with an artefact. The human moves upstream to define the task and downstream to judge the result.

The Nielsen Norman Group described generative AI as the first new user-interface paradigm in sixty years: users state an intended outcome instead of issuing the exact commands required to produce it. That is a strong claim, but the practical test is modest. Pick one recurring task. Can you specify the result clearly enough for software to attempt the whole job? Can you verify the result without repeating the job yourself?

If the answer to either question is no, adding an agent only makes the mess run faster.

Redesign one workflow before buying more tools

Start with a task that is frequent, bounded, and easy to check. A weekly status report works better than “help run the company.” A pull-request update works better than “improve the codebase.” A meeting brief assembled from five known documents works better than open-ended research across the web.

Write the task as a small contract with four parts: outcome, inputs, constraints, and the evidence required at the end. For a status report, that could mean: produce a 300-word update from this project board and these meeting notes; use the team’s standard headings; do not invent dates or owners; return links to every ticket mentioned. Those rules define what can be checked.

Keep stable context outside the prompt. Put terminology, priorities, style examples, and standing rules in a versioned file. Give the agent that file on every run. Avoid relying on a long chat history to preserve the operating model. Chat histories are hard to audit, easy to contaminate, and awkward to update. A plain `AGENTS.md`, a project brief, or a folder of approved examples gives the system a visible source of truth.

This also targets the “digital debt” described in Microsoft’s Work Trend Index: the email, meetings, searches, and small coordination tasks that consume attention before substantive work starts. Natural-language access can reduce some of that load, but only when the agent receives the right context. Otherwise, you save time on formatting and lose it again correcting bad assumptions.

Run the workflow manually once while recording each input, decision, and output. Then delegate the repeatable parts. This exposes the judgment that experienced operators apply without noticing. If you cannot explain why you accepted one source, changed one number, or escalated an exception, an agent cannot apply that judgment reliably. The recording becomes the first specification.

Build a review lane, not a prompt habit

Single prompts encourage a bad habit: ask, watch the answer appear, tweak the wording, ask again. That is still hands-on operation. The better pattern is a managed run with a queue, an output location, and a review state.

Andrew Ng’s discussion of agentic workflows outlines several mechanisms that improve results over a single model response, including reflection, tool use, planning, and collaboration between agents. Those mechanisms do not guarantee correctness. They do make it possible to split a task into inspectable steps and to retry failed steps without restarting the whole job.

For each run, require receipts that match the risk. A research task should return its sources and quotations. A coding task should return a diff and test output. A spreadsheet task should identify changed cells and the source for each imported figure. A scheduling task should return a draft invitation before sending it. The summary gives orientation; the artefacts make review possible.

Send every result to one queue: a project board, a shared channel, or a folder with simple states such as `needs-review`, `approved`, and `rework`. Then reserve review time. Asynchronous execution without an inbox produces a graveyard of drafts. Two short review windows work better than a day of sporadic notifications because they separate production from judgment.

Set escalation rules before the first run. Let the agent make reversible, low-cost decisions within a defined scope. Require approval for production changes, customer messages, purchases, legal edits, deletion, or access-control changes. The exact boundary depends on the work. What matters is that the boundary is written down and the system stops when it hits it.

Review the process as well as the output. If the result is wrong, identify whether the failure came from missing context, a vague definition of done, a bad source, an unavailable tool, or faulty reasoning. Then change the relevant instruction or workflow step. Avoid stacking paragraphs onto one giant prompt. Small, named rules are easier to test and remove.

Measure approved output and preserve expertise

The management analogy helps only if it changes what you measure. Time spent typing tells you little once an agent executes part of the work. Track completed runs, approval rate, review time, rework rate, and serious errors caught before release. These measures reveal whether delegation saves time or merely relocates effort.

Version the briefs, context files, and approval rules. When a change reduces approval rates across several real tasks, roll it back. Keep a small test set of representative jobs and rerun it after changing a model, tool, or instruction. This is ordinary operational discipline applied to software that produces variable output.

Expertise becomes more visible in this setup, not less necessary. A staff engineer spots a dangerous abstraction in a plausible diff. An editor notices when a clean paragraph dodges the central question. A lawyer distinguishes a harmless wording change from a shifted obligation. The agent can accelerate drafting, but the expert still defines acceptable work and catches costly failure.

Junior development needs deliberate protection. If agents absorb routine drafting, searching, and formatting, newer colleagues lose the repetitions where judgment forms. Give them responsibility for reviewing receipts, explaining rejected outputs, and improving task specifications. They should learn why work passes, rather than approving polished text without scrutiny.

Start this week with one workflow that takes between thirty minutes and two hours and recurs often enough to compare results. Write the four-part task contract. Save the context in a file. Define the approval boundary. Require evidence. Run it three times, record review and rework time, and keep the workflow only if the numbers improve. That is enough to discover whether you are managing delegated work or running a more complicated autocomplete.