When AI Takes Over the Steps, What Keeps Enterprise Software Essential?

Select a passage in a collaborative document, ask an agent to look up a figure and add a chart, and the work can keep moving. Take that logic one step further: if agents can connect to data, write documents, and submit code, does enterprise software need anything more than backend interfaces?

That conclusion skips over the hardest part of software to replace. Retrieving a number is one task; deciding what the number means is another. Generating a proposal and getting a team to agree on it are not the same thing either.

Enterprise AI competition will increasingly turn on these distinctions. Agents can take over steps, but design, professional judgment, organizational context, and working relationships do not disappear. As implementation becomes easier, software must answer a harder question: why should users still work here instead of handing everything to a general-purpose interface?

Agents Can Take the Steps, but Expert Interfaces Preserve Room for Judgment

To assess whether an interface still has value, start with the structure of the task.

When the job is to retrieve a figure defined by an agreed metric, organize confirmed meeting conclusions, or route tickets according to explicit rules, users mainly care about the result. If the input and acceptance criteria are clear enough, an agent can indeed compress menus, copying and pasting, and navigation between pages. Preserving every existing interaction does not automatically create value.

But design, analysis, and cross-functional trade-offs often have no predetermined right answer. People need to see differences, adjust details, compare effects, and sometimes redefine the problem through the act of working on it. A designer moving an element, a project lead comparing two schedules, and an analyst changing a statistical definition are all using the interface to think.

If this kind of software is reduced to “type a prompt and wait for an answer,” it may remove not only the operations, but also the conditions people need to understand the work.

General-purpose agents, specialist agents, and product interfaces can therefore coexist. General-purpose agents help users move work across tools, specialist agents perform actions within a domain, and product interfaces support comparison, control, and collaboration. Each has an appropriate scope; the rest do not inevitably have to be swallowed by a single universal entry point.

Atlassian’s official documentation for Rovo MCP shows one implementation of an agent entry point: external AI tools can read information from Jira and Confluence and perform supported actions, while access remains constrained by identity, permissions, and organizational configuration.[1] MCP can be understood as a standard interface through which agents invoke software capabilities. Opening such an interface does not conflict with maintaining a strong product experience.

Imagine a project lead drafting a brief in Confluence and suddenly needing a business metric. An agent could connect to an external data tool and return the answer, its source, or a small chart, allowing the lead to continue writing. That does not turn the document application into a full data analytics platform.

If the task becomes long-term modeling, anomaly investigation, or revision of data definitions, specialist tools still need to provide deeper control. Figma’s design environment, and the professional data work supported by Databricks or Snowflake, cannot be reduced to a one-off invocation. Giving an agent access to a capability and having the host product fully replace a specialist tool represent two different product boundaries.

The more useful questions for software teams are these: after an agent takes over the steps, can users see differences more clearly? Can they still control important outcomes? Can specialist work continue without disruption? People do not need to watch an interface continuously for stable, repetitive, low-risk background tasks. But when an exception or disagreement arises, there should still be a way back into the work.

Once Features Are Easy to Copy, Design Creates the Difference

AI has lowered the barrier to implementing some features and made similar capabilities easier to reproduce across products. In that environment, “we can generate, search, and summarize too” will become an increasingly weak reason to choose one product over another.

Design becomes more important, not less. Users may not know what they can ask for, when the system should intervene, or whether an answer is ready to use. A capable model does not mean the product has successfully put that capability into users’ hands.

A text box may look flexible enough, but it leaves much of the work to the user: discovering what the system can do, composing the request, explaining the current task, and then deciding whether the result is usable. If users continue to treat a powerful model as an ordinary search box, the problem may be that the product has not presented a clearer way to use it.

Good design closes these gaps. While someone is writing a document, the option to retrieve a figure should appear where evidence is needed. When comparing proposals, the interface should preserve the options, their differences, and room for revision. Before an agent changes a shared object, users should be able to see the scope of the impact. A capability that appears at the right moment is more useful than a row of “AI features” displayed on a home page.

Design here includes visual and interaction design, but also product purpose, workflow, collaboration, and exception handling. Reducing it to an approval button misses most of the value as well.

The engineering problems have not disappeared. Reliable execution, system integration, and performance optimization still require investment. But feature implementation is no longer the only source of differentiation. A product must also let people understand it when necessary, control it, and trust it with the next piece of work. A growing feature count cannot substitute for that experience.

Once Agents Can Act, Interfaces Must Explain Whom They Represent

When an agent can only offer advice, the interface mainly needs to explain the answer. Once an agent starts editing documents, submitting code, or advancing a process, the interface must also explain the action.

Consider Codex creating a code change request. “Done by the engineer,” “done by the agent,” and “done by the agent on the engineer’s behalf” give collaborators different understandings of what happened. Whether the initiator supplied only a one-line instruction, participated in the changes, reviewed the diff, or approved the merge can all affect subsequent judgment.

Listing a person as the committer hides the execution process. Listing only the agent loses the authorization relationship. Initiating the task, executing it, editing the result, reviewing the change, and bearing business responsibility may also belong to different roles.

Products should record these relationships and display them where judgment is required. Applying one universal label to all content can show that a tool was involved, but it cannot fully express authorization, contribution, modification, and responsibility. Content written by a person and then polished by AI does not carry the same collaborative meaning as a task delegated entirely to an agent.

More detailed records do not mean putting the entire execution trace in front of every reader. Details of low-risk actions can remain collapsed and expand when an exception occurs. Actions that affect production systems, customers, or important business records need sufficient information and opportunities for confirmation before a consequential change. If everything triggers a dialog, confirmation becomes mechanical clicking.

An action log is also no substitute for checking the result. Anthropic’s material on agent evaluation distinguishes execution traces from the final state of the environment: an agent saying that it finished does not mean the correct result actually appeared in the target system.[2] Enterprises must also inspect the actual object, version, and state, and verify that the change remained within authorized permissions.

The design objective here is specific: collaborators should be able to see who changed what, under whose authority; the person responsible for approval should be able to make an informed judgment; and a recovery path should exist if the action fails.

Understanding a Company Depends on Relationships and Validity

Connecting internal files to a model does not mean the model understands the company.

Enterprise knowledge is scattered across documents, presentations, meetings, project systems, code, and relationships among people. The same question may have an old proposal, a later decision, and an exception currently in effect. Finding a relevant sentence solves a retrieval problem; it does not necessarily produce an answer that can be acted on.

Organizational context must connect these objects: who owns the project, which material reflects the current state, who made a decision, whether a later change superseded it, and what information the current user is allowed to see. Context includes content, but also relationships, status, and permissions.

Atlassian defines Teamwork Graph as a unified data layer connecting objects such as work items, documents, people, and projects. Its connector permissions documentation also states that changes in source-system permissions need to be synchronized with search access.[3] These are the vendor’s descriptions of its architecture and behavior, not proof that a graph can automatically and completely understand any enterprise.

The approach is nevertheless worth examining: make organizational information searchable and connected before an agent asks a question, rather than starting each task from a new pile of scattered files. Well-prepared context can help the system find relevant evidence more quickly. How much time and cost it actually saves still needs to be measured in specific workflows.

This context must do two things at once: stay current and preserve useful memory.

“Someone currently owns this project” must be updated when responsibility changes. “The team has previously been delayed by this type of dependency” may remain useful for much longer. Old facts must not continue to masquerade as the present, but historical experience should not be discarded simply because it is old.

A person’s early code may no longer be directly useful to today’s task, while the fact that they once worked as an engineer may still help the system choose an appropriate explanation. The value of history sometimes lies in the understanding distilled from records, rather than in preserving every detail unchanged.

Imagine an agent answering, “Why was this feature not released?” An early proposal, an obsolete schedule, and a recent change decision may all contain relevant phrases. Without validity periods and relationships among decisions, the system can easily present a long-withdrawn reason as the current explanation.

More information does not mean all of it should be sent to the model every time. Anthropic’s material on context engineering argues for selecting enough high-signal information for the task, rather than loading everything available.[4] An organization’s knowledge store can be rich, while retrieval for each execution remains selective.

There is no need to begin with a massive graph. A clearly bounded process can develop useful context by first organizing its key records, owners, validity periods, and access rules. More complex connections can then be added in response to real problems.

A Specialist Model’s Advantage Must Survive the Next Comparison

Specialist models can be valuable, but neither “industry-specific” nor “proprietary model” is a sufficient reason to buy one. The question is whether it can continue to deliver an advantage in quality, speed, cost, or deployment for the target task.

Several concepts are easy to conflate. A small model describes scale; a specialist model describes task scope; fine-tuning describes a training method. Fine-tuning an existing foundation model is not the same investment as training a foundation model from raw data. Fine-tuning can be highly useful, but the name of the training method does not prove a durable advantage.

A specialist system’s lead can also change with the benchmark. A new general model, better retrieval, or clearer tool definitions may erase an advantage seen in one evaluation. A supplier leading now does not mean the same data and methods will keep it ahead.

Procurement and R&D teams need to ask more specific questions: What is the target task? Can the training and evaluation data be updated continuously? How are ambiguous cases handled? Who maintains the system when new tasks appear? Once deployment and human review are included, is it still economical?

Apple’s research on Projected Language Models provides evidence for training small models in constrained domains: limiting the domain and applying suitable methods can improve in-domain language-modeling performance.[5] But the research did not directly test tool use or approval workflows in enterprise agents, so it cannot support a claim that small models have comprehensively replaced large ones.

Ticket classification can be evaluated against ambiguous descriptions and rare categories in real tickets. Tool use requires checking parameters, authorization, failure recovery, and the final result. Correct formatting only shows that the output passed one check; it does not prove that the business outcome is correct.

A specialist system may sustain a long-term advantage where proprietary data keeps accumulating, task boundaries are stable, or deployment constraints are stringent. Where open-ended tasks continue to expand, retaining a general model and a path for human intervention may be more appropriate. The harder-to-copy assets are often high-quality task data, acceptance criteria, and the ability to keep finding failures—not the label “proprietary.”

Cheaper Inference Does Not Mean Unlimited Enterprise Consumption

Even if the inference cost of each unit of capability continues to fall, it does not follow that enterprises will increase valuable usage without limit.

A phone having processing power does not mean its processor must run at full capacity all the time. The analogy is useful because it separates what can be used from what is worth using, but it cannot predict a specific level of demand. Enterprise adoption is also constrained by process redesign, training, allocation of responsibility, employee attention, and business returns.

Technology may produce features faster, while organizations cannot necessarily absorb them at the same pace. One more agent-generated report that nobody needs adds a reading burden. One more notification that changes no decision does not constitute delivery. More calls can simply make existing information noise louder.

This changes the order of cost management. Early on, the priority is to test whether the experience genuinely helps users complete work and whether they want to use it repeatedly. If nobody is willing to adopt it yet, focusing on saving money per call may amount to optimizing a feature nobody needs.

Early exploration still needs budget and risk boundaries. But cutting quality too soon to save a few cents can ruin an experience that would otherwise have been valuable.

As a system prepares to scale, cost discipline must become more granular. Model routing assigns different tasks to suitable models. Runtime frameworks reduce unproductive steps and retries. Gateways help manage calls and budgets. These capabilities can be built or bought; the choice depends on call volume, technical capability, and control requirements. Building in-house is not in itself a sign of maturity.

Cost must also be measured per acceptable result. A single task may involve retrieval, multiple calls, failed attempts, and human review. If a lower-priced model requires frequent rework, remediation may consume the savings. If a more expensive model reduces review, it may be more economical for some tasks.

One practical measure is to add up the cost of calls, retrieval, retries, human review, and operational maintenance over the same observation period, then divide it by the number of business outcomes that pass acceptance. Comparisons should hold task scope, quality standards, and risk requirements constant, so that lowered standards are not mistaken for improved efficiency.

Anthropic’s material on agent engineering recommends starting with the simplest approach that solves the problem and adding complexity only when necessary. It also notes that agents may trade higher cost and latency for better task performance.[6] Rules, lightweight models, powerful models, and human confirmation each have their place. Routing decisions should come from task testing, not from the pursuit of lower prices alone.

The Application Moat Is Found in Collaboration

If models can produce equally fluent prose, what value remains in document software?

A team document is more than text. It may carry sources, versions, review comments, project relationships, and follow-up tasks. Who can see it, who can edit it, which decision has taken effect, and what another person should do next all determine whether the content can enter the flow of work.

There is therefore a wide gap between generating text and supporting team collaboration. The harder-to-replace assets of an application come from understanding the purpose of the work, connecting context, delivering a professional experience, and embedding itself in the process. A general-purpose interface may invoke a point capability, while the original application continues to support the judgment and collaboration that follow.

This does not guarantee an everlasting moat for incumbent software companies. As model providers move into the application layer, they can also build workflows, connect systems, and improve the experience. Incumbents that rely on legacy processes for too long may lose users. The boundaries will continue to shift, and cooperation and competition can occur at the same time.

A more useful test is where users’ work actually moves forward: whether information is easier to find, decisions can carry through, professional control is preserved, and the next colleague can understand and use the result. Existing products must prove their value through these outcomes, not merely by claiming, “We hold the enterprise data.”

Another easily overlooked cost is human attention. Agents can keep generating, prompting, and pushing actions, but direction, architecture, and consequential trade-offs still require thought uninterrupted by fragmented messages. Protecting space for slow thinking is not a rejection of rapid experimentation. It prevents faster execution from replacing judgment about what should be executed.

Temporarily remove the counts of reports, agents, and calls from the dashboard. The enterprise should still be able to see a change: the team reached a judgment faster, a decision was executed accurately, and the next colleague could pick up the work. Those are the outcomes worth further investment.

References

[1] Atlassian Developer, “Atlassian Rovo MCP Overview.”

[2] Anthropic, “Demystifying evals for AI agents,” January 9, 2026.

[3] Atlassian Developer, “What is Teamwork Graph”; Atlassian Support, “How Teamwork Graph connector permissions are kept in sync.”

[4] Anthropic, “Effective context engineering for AI agents,” September 29, 2025.

[5] Apple Machine Learning Research, “Projected Language Models: A Large Model Pre-Segmented Into Smaller Ones,” 2024. The experiments focused on domain language modeling.

[6] Anthropic, “Building effective agents,” December 19, 2024.