Fast Tech, Slow Org: The AI Execution Gap

The full conversation with Leandro Perez, SVP & CMO, ANZ Salesforce - is now live, listen to it now on your preferred streaming platform - HERE.

---

You deploy it, you own it

In the last 7 weeks I've watched three Australian organisations deploy AI agents into live customer-facing processes before anyone defined who owns the outcome. The tech went live on a Friday. By Monday, leadership was asking who approved it.

I've said this before - agents need an owner, and they're going to be on the org chart. Last year I made the case: the org chart shift in September, and agent accountability in the boardroom in November.

Salesforce is the clearest public example of doing this right - over 300 agents now operate inside the business - but the pattern I'm seeing is the same in mid-market companies a fraction of that size.

In my conversation with Leandro Perez, Salesforce's Senior Vice President and Chief Marketing Officer for Australia and New Zealand, he said every one of those agents is managed by an individual or team.

Leandro also shared a comment from Salesforce's CEO: this may be the last generation of managers who only manage people.

That shift is already visible in live work. Agents are contacting prospects, answering customer questions and moving information through internal workflows. The manager's responsibility now extends to the job the agent performs, the authority it carries and the consequences of its output.

The agent goes live before the business has defined its job, owner, authority, success metric, supervision, escalation path or the workflow that changes around it.

The board sees tools, pilots and agents in production. The P&L may still see very little.

Old approvals remain. People check the increased volume. Exceptions return to the same teams. Time savings disappear into review and rework because nobody decided which work should stop or where the released capacity should go.

The agent can be live while the organisation remains unprepared to carry the result.

A live agent can still be unmanaged

Leandro described an earlier Salesforce website agent that could follow up with customers at any hour.

It started contacting people on weekends and outside normal working hours. The agent followed the instruction it had been given, but the job lacked the timing boundaries and customer-contact conditions normally attached to sales work.

Salesforce changed the operating rules so it behaved within normal working hours.

A person entering a sales role usually receives a territory, working hours, approval limits, expected conduct, measures and a manager. An agent entering the same workflow needs the same level of operating clarity.

Deployment only proves that the technology can perform a task. It does not prove that the business has defined how the task should be performed inside a live customer relationship.

The exposure increases with the agent's authority.

An agent researching accounts creates one level of risk. An agent sending messages, updating customer records or making an offer creates another. The manager needs to know which actions are permitted, which require approval and which conditions should stop the workflow.

That becomes more important when the agent can repeat an instruction across thousands of interactions. A small gap in the job definition can become live customer behaviour before anyone reviews it.

The management job continues after launch. Someone has to inspect outputs, review exceptions, adjust instructions and decide when a person must step in.

Without that ownership, the agent can create more work than it removes. Every approval stays. Every exception returns to the same people. Managers inherit a larger queue and higher output while review and rework absorb the capacity the agent was supposed to release.

Bad information becomes live work

Salesforce found another management problem inside customer support.

Leandro said its support agent surfaced knowledge articles that had not been reviewed for years. Some remained untouched for as long as 20 years and contained outdated product information.

The information problem already existed. The agent applied it to current customer work at greater speed.

Salesforce initially treated the support agent largely as an IT project. Support engineers were later given greater control because they understood the customer questions, product history, language and exceptions well enough to see where its answers failed.

That operating detail matters.

Technology teams can manage architecture, access, security and technical controls. They cannot determine every customer exception, identify every outdated article or judge whether an apparently correct answer will hold up in the work.

Domain experts need to remain close to the agent after launch. They improve the instructions, review the source material and identify the exceptions that technical monitoring will miss.

The information also needs an owner. When a policy changes, a product is withdrawn or an exception becomes common, someone has to update the source and test how the agent behaves afterwards.

Otherwise, an organisation can keep improving the agent while leaving the underlying information failure in place.

Ownership follows the job

Technology should own the architecture, permissions, security and technical controls.

The business owner defines the job and carries the result.

Domain experts improve the source material, instructions and exception handling. One named manager owns supervision and escalation.

For a prospecting agent, the sales leader owns the pipeline result and the customer-contact conditions. For a support agent, the service leader owns resolution quality, customer impact and cost-to-serve.

Technology can confirm that the agent is available, secure and completing tasks as designed. The business may still be seeing poor conversion, repeat contacts, unnecessary reviews or no reduction in cost.

Both views can be accurate. One manager has to bring them together and make the operating decision: change the instruction, narrow the authority, fix the workflow or keep the agent out of production.

Executive ownership sits above that manager. Someone still has to decide which work stops, which approvals change and where released capacity goes.

Leaving every handoff in place gives the agent more opportunities to produce output without changing the economics of the workflow.

Agents expose weak metrics

Leandro explained that Salesforce also had to reconsider how it measured agent performance.

A human sales team has limited working hours. Measures such as conversations started, follow-ups sent and time spent engaging prospects can provide some indication of effort within that constraint.

An always-on agent changes the constraint. It can begin more conversations, send more follow-ups and remain active for longer without improving the commercial result.

Activity becomes easier to produce, so it becomes weaker evidence of value.

In sales, outreach volume needs to connect to qualified pipeline, conversion, revenue or selling time released.

In service, conversation volume needs to connect to resolution quality, customer satisfaction, repeat contact or cost-to-serve.

Inside an internal workflow, document volume needs to connect to cycle time, rework, cost or capacity moved into a named priority.

An agent can outperform its activity target while creating more work for people to check through the same approvals and handoffs.

The baseline is part of the management system. If the organisation does not know the current conversion rate, resolution quality, cycle time, rework or cost, higher activity can look persuasive because there is no commercial measure beside it.

The manager needs a before-and-after view tied to the job and workflow the agent changed.

AI Operating Readiness Test

The AI Operating Readiness Test is designed for one live agent or pilot. It checks whether the management conditions around the work are strong enough for controlled production.

Use the score interpretation printed on the asset.

A weak score means the operating conditions remain unclear. Keep the agent in pilot while the job, owner, authority, metric, supervision, escalation path or surrounding workflow still depends on assumption.

Run the test against observed behaviour from the pilot. Use actual outputs, exceptions, approvals and customer impacts. The owner should be able to explain the result without handing the question back to the project team or vendor.

Two checks still sit around the test.

First, confirm that the information available to the agent is current, approved and suitable for the job.

Second, name where any released human capacity will go. Hours saved without a destination tend to disappear into more checking, meetings and unresolved work.

My full conversation with Leandro Perez covers the out-of-hours customer contact, the stale knowledge behind Salesforce's support agent, why old activity measures lose meaning and what managers need to own next.

Listen to it now on your preferred streaming platform - HERE.

Run the test

Before your next steering committee, pick one live agent or pilot and run the test. Keep it in pilot when any of the seven answers remains unclear. Move it into controlled production once one accountable manager can give a plain answer to all seven.

Remember you can't stop the speed of change, but you can change how quickly you adapt!

Until next time, Ramon.

---

Applied AI Australia

Applied AI Australia helps executives turn AI into measurable business outcomes. We filter every initiative through one question: Does this increase revenue or decrease costs? If not, it's noise.

Leaders do not need more AI hype. They need to know which decisions AI should change, what risk it creates, and how to get value without creating chaos.

I am not a career consultant. I am a leader with 15 years of P&L experience, most recently as an executive at News Corp.

Following our acquisition by Acquire Intelligence, we combine this approach with a 10,000-strong global team that delivers enterprise execution.