The software America actually runs on

Connecting an agent to SAP and Salesforce doesn’t tell it why the operator keeps opening Excel.

That’s the part I’d want to understand before automating the job. A spreadsheet may carry the latest calculation; an email may contain the approval that lets the transaction move forward.

Some of those detours waste time. Others are controls the company depends on. I’d want the agent to learn the difference from the person doing the work before we ask it to simplify anything.

I'd want the person maintaining that spreadsheet in the room when we plan its replacement.

The meme is from 2024; Williams had replaced the spreadsheet by 2025.

A process transformation lead at a Big Four consultancy once explained why a decade of process mining had missed some of his banking clients' most important work.

A transaction started in System A. Someone moved it into an Excel spreadsheet, checked a note they kept for themselves, and eventually entered the result into System B. The process-mining software needed one data element it could trace from beginning to end.

This job had no such ID.

A system of record can tell you the state of an object. It rarely tells you why the operator took the next step.

We saw this in an inbound sales process at a large SaaS company. After a specific action in Salesforce, a rep opened LinkedIn to size the customer before setting the fee. The workflow included a custom Salesforce field that the team lead had built himself.

No official playbook mentioned the LinkedIn check. The rep had learned that it produced a better fee decision, so it became part of the job.

An event log can show that Salesforce and LinkedIn were opened. It cannot tell you what the rep learned, which Salesforce action prompted the check, or how that information changed the fee. Those details live with the operator.

Giving an agent access to the right applications solves only part of the deployment. The agent also needs the sequence, the handoffs, and the reasoning that connects one system to the next.

People talk about SAP, Oracle, and Salesforce as legacy software. Inside a large company, those systems hold the customer records, financial controls, permissions, and audit history that keep the business running.

The custom parts often matter most. A model may know Salesforce as a product. It does not know which field your sales team built, which button your administrator renamed, or which record has to be checked before an opportunity advances.

The same is true of the spreadsheet everyone wants to eliminate. It may contain the freshest calculation because the system of record updates overnight. The email approval may exist because a regional leader has authority the software never encoded. A personal note may hold the exception rule an experienced operator applies.

Before replacing Excel, I'd want to know what else had adapted to it.

Some of these practices are bad and should disappear. Others are controls the company depends on. You cannot tell which is which from the application list.

An agent project has to preserve the important controls before it changes the stack. That requires watching the job across the systems and asking the operator what each detour accomplishes.

We recently spoke with a global retailer that had mapped every customer-support process in Visio. It had Salesforce Service Cloud, Agentforce, Copilot, and roughly 1,400 support agents.

The automation was still stuck.

Every connection to an enterprise service required a ticket. Those tickets went to teams with huge backlogs. The company had process maps and AI tools, but the agent could not reach the systems it needed to do the job.

I would map readiness at the workflow level. List every system the job touches. Record whether the agent can read it, write to it, or has no approved connection. Then identify the smallest version of the workflow that can run with the access already available.

A readiness score should distinguish a workflow with four of five required systems connected from one with no approved connection. Calling both an AI pilot hides the difference that will determine which one ships.

The integration backlog becomes a deployment plan when it is attached to specific jobs.

The first useful version of an enterprise agent will usually work through the systems the company already trusts. It reads the current record, follows the existing approval path, writes back to the system of record, and stops when the process requires a person's judgment.

That approach looks less ambitious than redesigning the whole process. It also produces evidence about which steps are stable, which detours add value, and which systems create unnecessary work.

Once the company can see the full job, it can simplify it with confidence. A duplicate spreadsheet can go away. A regional approval can become a rule. A custom field can become a shared standard. The agent can take on more as the underlying process becomes clearer.

At WIQ, we capture that job as a blueprint: the steps, systems, decisions, and handoffs an agent needs to follow. The blueprint sits across the stack because the job does too.

Enterprise AI will run on SAP, Salesforce, Outlook, Excel, and custom internal software for a long time. An agent has to understand how the company uses them together.

We collect more examples and practical guides for deploying agents into this environment at getwiq.ai/resources.