Most teams should not begin by replacing their apps. Keep the systems that hold shared truth, let agents operate them where the work is messy, automate the stable handoffs, and build only when a recurring gap has a real owner.
The uncomfortable moment comes after the impressive demo. A project lead asks an agent to update a weekly status, then a client challenges the result. The lead can see that the status changed but cannot reconstruct which document, message, or assumption caused it. Delegation felt convenient until someone had to defend the answer.
The useful question is therefore not whether an agent can click through an app or generate a replacement. It is which failure you are prepared to own.
The App Holds More Than Its Screens
An app is easy to mistake for its interface. If an agent can navigate that interface for you, it can look as though the app has become unnecessary. Yet the durable value often sits underneath: record identity, shared fields, permissions, history, validation rules, and the agreement that this is where the current state lives.
Organizational software sits on a spectrum between institutionalized systems and improvised work. Payroll, candidate stages, approved drawings, purchase orders, and contract records tend to be institutionalized. The spreadsheet beside them, the weekly reconciliation, and the one-off report assembled from five sources are often improvised.
Agents push the boundary because they can handle more of that improvised work and can help build software for gaps that once went untreated. That changes the buy-versus-build threshold. It does not erase the need to decide where durable truth and responsibility belong.
The demo misleads in a specific way. It shows the part of the work that was always easy to describe, and hides the part the organization spent years agreeing on.
Among the 1,719 participants in McKinsey’s 2026 survey across 97 nations, 32% reported that their organization had decided against at least one software product or feature because it built the functionality with agentic coding tools.
That is a report of decisions by survey respondents. It does not show that 32% of all companies did so, or that the resulting tools succeeded, saved money, or replaced the underlying systems.
Choose by the Failure You Can Live With
Start with two questions: how much interpretation does the work need, and how costly would a wrong action be?
| Choice | Best Fit | Warning Sign |
|---|---|---|
| Keep or buy the app | Shared records, mature permissions, standard workflows, high-consequence work | The friction comes from cross-app coordination, rather than the app itself |
| Let an agent operate apps | Retrieval, preparation, reconciliation, and drafting with frequent exceptions | People cannot inspect what the agent read, changed, or prepared |
| Automate the flow | Stable triggers, fields, rules, and supported interfaces | Exceptions turn a clear rule into a maze of special cases |
| Build a narrow layer | A valuable repeated gap with stable inputs, an accountable owner, and a clear exit | The prototype has no maintenance, security, or recovery plan |
Payroll, regulated records, and access control carry requirements that a generated interface does not make disappear. An agent can assist with preparation or navigation while dedicated software retains the transaction and controls.
Interface quality changes the risk. A supported API or connector offers named fields, authentication, and clearer failure responses. Browser operation can reach a site without an integration, but it depends on screens, labels, page state, and content the agent encounters.
For example, in its built-in browser, Claude Cowork can navigate, read, click, and type in a separate browser context. Its safeguards reduce but cannot eliminate prompt-injection risk. A page that changes frequently, or an update that can leave several systems out of sync, needs a recovery path before browser operation becomes routine.
Approval design matters most when the action changes the outside world. For another example, Microsoft’s Cowork carries out multi-step work across Microsoft 365, shows its steps, and asks for approval before consequential actions such as sending or scheduling. That is a product-specific pattern, not a guarantee shared by every agent.
For coding projects and productivity tools, my preference is to give the agent room to prepare a complete result, then put approval beside the consequential change. An agent that asks permission for every harmless step is tiring; one that sends a promise before I can inspect it is too autonomous for my liking.
Architecture Coordination: Preserve the Evidence Chain
Imagine an architecture project with meeting minutes in one folder, approved drawings in a document platform, open issues in a project system, and commitments scattered through email. The project manager wants one current status brief before a client meeting.
An agent can gather the named sources, match issue owners, find dates, and draft the brief. It may also spot that the meeting minutes refer to a newer drawing revision than the issue register.
That conflict belongs in the brief. The agent should surface both versions, show their locations, and ask the responsible person to resolve the disagreement before updating the project status.
The document and project platforms remain the records. The agent’s brief is a view assembled for a purpose. Contractual interpretation, an external statement about delay, or a final change in project status still needs a person who can evaluate consequences and stand behind the decision.
Conventional automation helps when the team has stable events, such as creating a review task whenever an approved drawing arrives. Agent operation fits the messy work of reconciling notes and explaining exceptions.
A custom coordination view earns its place only after projects share stable fields, owners, permissions, and an update rhythm. It should preserve links to the underlying revisions and issues so that a reader can trace how the status was assembled.
The manager’s real fear is not that the agent will be slow. It is having to defend an on track status whose evidence chain disappeared inside a convenient interaction.
Recruiting: Administrative Help Is Not Hiring Judgment
Now imagine a recruiter preparing an interview round from application materials, portfolios, and interviewer calendars. An applicant tracking system (ATS) holds candidate identity, stage, and process history.
The useful division is by responsibility:
- Automate agreed rules: Match available slots and schedule an approved panel when the participants and constraints are settled.
- Delegate preparation: Assemble supplied documents, flag missing information, and propose options when an interviewer’s availability is ambiguous.
- Keep hiring judgment visible: A person reviews assessments, sensitive inferences, stage changes, and candidate-facing messages before they affect the process.
Slow screens are a weak reason to recreate the ATS’s identity and access controls. If the agent finds two similar names or a possible duplicate, it should reconcile identity before any write.
Improve the Interview Packet Without Creating a Second ATS
A narrow custom tool may still be justified. Perhaps the organization repeatedly assembles the same internal interview packet and the ATS cannot express that view. Build the view only if its input fields, retention rules, access, write-back path, and maintainer are explicit. The tool can improve preparation without becoming an untracked second hiring system.
I would be more comfortable delegating the assembly of an interview packet than accepting an unexplained candidate ranking. A summary can shape a hiring decision even when the agent never changes a stage. Keep it tied to the supplied material, and make gaps visible instead of filling them with a confident inference.
Project Operations: Separate Intake From Commitment
Consider a small consultancy receiving work through a form, client email, shared documents, and meeting notes. Someone must turn that intake into tasks, priorities, owners, and client expectations.
Three kinds of work are mixed into that one request:
- Predictable intake: A form creates an intake record; a confirmed project code routes it; known fields prepare a standard acknowledgment. Conventional automation fits these settled mappings.
- Interpretation: An agent reads the request, finds the relevant scope document, drafts tasks, and flags contradictions or missing information.
- Commitment: A person decides whether the request changes price, delivery date, priority, or a promise to the client.
An agent might turn a client’s request for a small addition into a sensible task draft. If the scope document excludes that work, it should flag the conflict. Creating the task and agreeing to deliver it are separate decisions. The task system and document store keep the accepted result; the raw request remains available if the interpretation must be revisited.
Make Partial Completion Visible
Browser operation can be practical during a trial, especially when a tool lacks a connector. But suppose the task is created and the document update fails. A useful result says which action succeeded, which failed, and what is safe to retry. A vague success message could send someone back through both steps and create a duplicate task.
Build a small intake front end or rule layer when the team repeatedly encounters the same stable gap and existing workflow automation cannot express it clearly. Keep the underlying project record and an exit route. Otherwise the team has exchanged awkward SaaS for a private dependency nobody planned to own.
Count the Human Work That Remains
The agent’s completion time is only one part of the productivity question. Someone still has to review its work, correct mistakes, and recover failed actions. A faster first draft can leave more work behind than it removes.
Take a batch of 100 intake requests. Handling each manually, including normal checking, takes six minutes, or ten human hours in total. Now suppose every agent-prepared request needs two minutes of review, and each request that needs rework takes another eight minutes to correct.
At a 20% rework rate, the batch takes six human hours. At 50% it takes ten, which erases the savings entirely. At 80% it takes fourteen, four hours worse than doing the work by hand.
In this example, review time stays fixed while rework changes the result. I would measure both before calling the agent a time-saver.
The Prototype Becomes an Obligation
An agent can help turn a small idea into a convincing prototype. That pleasure creates its own pressure: because the prototype works once, colleagues can treat it as a promise that someone will keep it working.
The part of agentic coding that appeals to me is being able to make a small tool fit a specific irritation. I would be much slower to turn that convenience into something colleagues depend on. Shared use creates duties that a convincing demo can leave out:
| When Something Goes Wrong | What the Shared Tool Needs |
|---|---|
| The wrong person can change a record | Authentication, role-based access, and a history of actions |
| One update succeeds while another fails | A visible error, a record of completed changes, and a safe retry or recovery path |
| A connected app changes its API or page layout | Error monitoring and a named maintainer who can repair and test the integration |
Someone also needs to own migration and retirement. If the maintainer leaves, the team should know how to export any unique data, return to the underlying app, and stop the jobs that depend on the tool.
Give Maintenance a Workload to Justify It
Suppose a custom layer takes 20 human hours to build and two hours a month to maintain. It saves three human minutes per task compared with the current workflow, after accounting for review and rework.
Over six months, building and maintenance consume 32 hours. At 100 tasks a month, the layer saves 30 hours of task work, leaving the team two hours behind. At 150 tasks a month, it saves 45 hours, leaving a net gain of 13 hours.
Under those assumptions, it takes about 107 tasks a month to recover the time within six months. Higher maintenance, lower savings, or a shorter useful life can reverse the decision. A distinctive capability may still justify the effort, but then judge it on that benefit rather than claiming it saves time.
I have more sympathy for the distinctive-capability argument than the time-saving one. A new capability can be worth maintaining even when it saves no time. Name the task it makes possible and who benefits from it.
Sunk SaaS cost can distort the decision in the other direction. Paying for an app does not make every feature worth keeping. Retaining its reliable records and permissions while replacing an expensive add-on or awkward surface may be worthwhile. Compare any avoided fee with the ongoing cost of integration, support, monitoring, and migration before calling the custom tool cheaper.
Run a Reversible Trial
Choose one recurring workflow whose current pain is specific. Keep its existing record in place and begin with read-only retrieval and a draft output. Compare the result with the source material, including where it needed judgment, where information was missing, and where a stable rule would have worked better.
If that stage is reliable, allow one narrow write with explicit approval and a visible change history. Test an awkward case alongside the ordinary one: conflicting versions, a duplicate person, a missing field, or a rejected destination. Can the person reviewing the work tell what changed and recover without guessing?
Use the trial to choose what to keep. If nearly every approved item follows the same fields and route, a deterministic automation may be easier to test than repeated agent interpretation. If the useful work lies in resolving varied requests, keep the agent and the review. Expand a custom layer only when the recurring benefit justifies maintaining it.
The outcome I would want is fewer chores between intent and finished work. An app can remain essential even when opening it becomes rare.