Building for People, Building for Machines

Building for humans and building for agents pull in different directions. The products that manage both will bring hidden demand into view.

Software has a second user. For 30 years, we built digital products around a person sitting at a screen: reading menus, filling forms, clicking buttons, and fixing mistakes. A growing share of software now has to serve an agent as well: a system that reads state, calls tools, takes actions, and hands back results. That creates a real design tension. Humans want clear interfaces and room for judgment. Agents need structured state, reliable actions, scoped permissions, and a way to recover when things break.

That shift matters because it changes demand, not only design. When valuable work becomes cheap enough to delegate, people start doing work they used to avoid. That is latent demand: demand that exists, but stays invisible because the time, attention, skill, or coordination cost stays too high. Agentic engineering is the work of lowering that cost.

From Prompting to Agentic Engineering

For most of the software era, humans were the bottleneck. Good products removed friction from the person in the loop. They made screens easier to scan, workflows shorter, defaults better, and collaboration less painful. The human still had to define the rule tree and babysit the exceptions.

Large language models, however, can map messy instructions onto structured actions. They can read an email, spot the task, choose a tool, and work through a sequence that would have broken older automation. That changes the unit of design. The product is now a screen and the system behind it: the data model, the permissions, the tools, the logs, the error states, and the handoff points.

That is why a polished interface can still leave an agent blind. A person can infer from hints. An agent needs those hints exposed.

A person can tell that a grey button means a missing prerequisite. An agent needs the prerequisite as state or an error code. A person can repair a broken workflow by improvising. An agent needs checkpoints, retries, and a route to escalate. A person can skim a dashboard and decide what matters. An agent needs the data behind the chart, not the chart itself.

Agents and the Return of Latent Demand

Designing for humans is about usability. Designing for agents is about operability.

Those goals overlap, but they do not line up cleanly.

Human-first products often hide complexity. They use soft defaults, flexible inputs, visual cues, and forgiving workflows. That is good design for people. Most users do not want to think about schemas, state transitions, or permission scopes.

Agent-ready systems need many of those details out in the open. They need explicit fields with known formats, stable actions, predictable outputs, granular permissions, clear policies, and logs that show what happened and why. They need safe ways to retry a step without doing it twice. They need a clean distinction between "task failed," "tool timed out," and "action not allowed."

Humans like a little magic. Agents need scaffolding.

You can see the tension in almost any workflow category. A human-friendly expense app can get away with loose inputs, a few smart guesses, and a tidy approval screen. An agent-friendly expense system needs merchant metadata, policy rules, reimbursement status, approval paths, and a clear way to submit, revise, or roll back a claim. A human-friendly CRM can lean on rep judgment and messy notes. An agent-friendly CRM needs a clean way to tell when 2 records refer to the same customer, rules for routing leads, activity history, and narrow actions with predictable outcomes.

For the next few years, the best products will probably carry 2 surfaces. One surface is for the person. It explains, approves, edits, and handles exceptions. One surface is for the agent. It exposes state, tools, policies, and traces. The human surface builds trust. The agent surface makes delegation possible.

The Interface Is No Longer the Whole Product

Agentic engineering is the practice of making software operable by agents under real constraints. It sits at the boundary between model capability and system reliability. Smarter models help, but they do not remove the need for explicit system design.

Agents need narrow actions with fixed inputs and outputs instead of one giant function that tries to do everything. Good tools expose clear inputs, predictable outputs, and meaningful errors. They also make repeated actions safe. If an agent retries a payment or a refund after a timeout, the system needs a way to recognize the duplicate and prevent damage.

An agent has to know what changed, what is still true, and what context persists across steps. That sounds obvious. In practice, many products scatter that context across emails, UI screens, spreadsheets, and tacit human knowledge.

Then comes verification. A useful agent checks its work against policy, tests whether the result matches the request, and asks for review when confidence is low or the stakes are high. The model matters here, but the engineering around the model matters just as much. Deterministic validators, business rules, secondary checks, and human approval gates do a lot of the heavy lifting.

Observability matters too. Teams need traces, costs, latencies, and failure modes. They need to know whether the agent saved time or created cleanup work. Without that visibility, the system can sound fluent while quietly drifting off course.

Permissioning may be the least glamorous piece, and one of the most important. An agent needs enough access to do the job and no more. Scoped credentials, narrow permissions, and approval paths turn an agent from a novelty into something a real company can trust.

When people talk about agents, they often focus on the model in the loop. The more durable advantage may sit lower in the stack: the workflow data, the permission graph, the evals, the traces, and the recovery logic. That is the part that makes a system dependable.

How Agents Change Product Economics

The economic piece is easy to miss if you only look at product demos.

Plenty of people want an outcome without wanting the job required to get there. They want books closed, leads routed, claims filed, codebases maintained, vendors compared, meetings summarized, and reports drafted. They stop short because the effort feels larger than the payoff.

That is latent demand. The desire is real. The observed usage is low because the cost of acting on that desire stays too high. Markets usually see revealed demand, not total demand. They miss the work people skip because the hassle swamps the value.

The key threshold looks like this:

value of the task > execution cost + review cost + failure cost + integration cost

Most AI product talk focuses on execution cost. Can the model write the email, summarize the document, or draft the query? That matters. It is only part of the equation.

Agentic engineering attacks the rest. It lowers review cost by sending only the messy cases to a human. It lowers failure cost with validation, rollback, and scoped actions. It lowers integration cost by connecting the tools, permissions, and state the task already depends on.

When that full cost drops below the value of the task, demand can jump fast.

Take CRM hygiene. Every sales team wants clean records, complete notes, enriched contacts, timely follow-ups, and accurate next steps. Very few get them. The work is too fragmented. Each step is small. The chain is long. An agent that can read the meeting transcript, update the account, draft the follow-up, log the action, and flag only the ambiguous cases makes a task that was perennially neglected worth doing every time.

The same pattern shows up in bookkeeping. Small businesses want cleaner books and faster closes. They rarely want 3 extra hours each week spent categorizing transactions, chasing receipts, and reconciling line items. An agent connected to bank feeds, invoices, policy rules, and the accounting system can do most of that work and raise its hand for the anomalies. The demand was always there. Labor costs kept it hidden.

Research is another good example. Investors, operators, and founders want broader scans, deeper diligence, more comparisons, and tighter monitoring than they can usually afford. They would run 20 more checks on a market, vendor, or target company if collecting the evidence, stitching it together, and citing the sources were cheap enough. Lower the cost of delegation and the amount of research a team chooses to do can expand sharply.

That gives us a decent rule of thumb. Agents create the most value first in coordination-heavy work: tasks that cross systems, break into many small steps, and produce frequent but manageable exceptions.

What Humans Like, Agents Can't Use

The most useful question for the next few years is simple: can this product let a user delegate valuable work with low enough oversight?

That question is more revealing than "does it have an AI feature?" or "how smart is the model?" A model can look brilliant in a chat window and still fail at doing real work inside a messy system. Delegation depends on the whole stack.

A few signals matter.

First, look for products that measure task completion, not engagement. The right metric is rarely "messages sent" or "time in chat." It is more often "tickets resolved," "claims processed," "records updated," "hours saved," or "exceptions escalated."

Second, look for dual-surface design. The winning pattern will often be a human control layer on top of an agent execution layer. Users set goals, review edge cases, and keep accountability. Agents do the routine work in between.

Third, look for systems that already own the data model and the approval path. Products that hold the source of truth, the permissions, and the action layer start ahead. API-first companies, which already expose actions in machine-readable form, start ahead too. Thin wrappers can help at the edges. Products that own the data, permissions, and workflow can finish the job.

Fourth, watch pricing. Seat-based pricing fits human-operated software. Work-based pricing fits delegated software more naturally. If the product closes books, routes leads, reconciles claims, or resolves tickets, charging by task volume or outcome may make more sense than charging by headcount.

There are real limits. It is still unclear how far open-ended agents can go in high-stakes domains with sparse feedback and costly errors. Healthcare, law, finance, and security will likely settle on supervised delegation before they tolerate wide autonomy. That still changes the economics. If an agent handles 80% of the flow and hands the risky 20% to a person, the value can be large.

The broader point holds. Software no longer serves only the person at the keyboard. It also serves the system acting on that person's behalf. That shifts product design from pure usability toward operability. It creates a new engineering discipline around delegation, verification, and control. And it brings hidden demand into view by making more work worth doing.

The next wave of software will be judged by how much work it can take off the board under clear accountability. Markets grow when the handoff gets cheap enough to trust.