The Agentic SI Firm Is Not a Rebrand. It Is an Operating Model

Every Salesforce SI firm now has a version of the same sentence on its website. AI-powered delivery. Agentic transformation. Faster implementations. Smarter consulting.

The problem is that the phrase tells a buyer almost nothing.

A Salesforce platform owner at a bank, healthcare company, manufacturer, or fast-growing SaaS business does not need another partner claiming to “use AI.” They need to know whether the firm has changed how it discovers requirements, writes statements of work, builds systems, tests agents, manages risk, prices delivery, and supports customers after go-live.

That was the harder question underneath TestZeus’ Humans of Testing webinar, “Becoming an Agentic SI Firm,” hosted by Radhika Gupta and moderated by Robin Gupta, CEO and co-founder of TestZeus. Robin framed the discussion as a buyer-side interrogation of the market: how does a customer separate genuine AI capability from marketing theater?

The panelists did not land on a neat consensus. That was the useful part.

Mitul Patel, Founder and CEO of Creatique Technologies, argued that “AI-powered” should mean something real, visible, and explainable in business language. Siddharth Sehgal, Founder and CEO of 360 Degree Cloud, cautioned that AI is still closer to a crawling child than a mature operator. Kishore BT, Salesforce MVP Hall of Fame member and Salesforce architect, pushed the conversation toward platform strategy, technical debt, metadata awareness, and the hard limits of generated output.

Together, they sketched a more demanding definition of an Agentic SI firm: not a consultancy that has added AI to delivery, but one that is rebuilding delivery around agents, trust, measurement, and continuous responsibility.

What Is an Agentic SI Firm?

An Agentic SI firm is a system integrator that uses AI agents as part of its operating model, not only as a client-facing service. It can identify suitable agent use cases, design governed agent workflows, define scenario-based success criteria, test nondeterministic behavior, monitor agents after launch, and price work around expertise and outcomes rather than inefficient hours.

That distinction matters because the market is moving faster than buyer confidence.

Salesforce’s own Agentforce positioning now emphasizes guardrails, trust controls, data protection, and hallucination reduction as central parts of the platform, not secondary concerns. Salesforce’s Summer ’26 release also pushed further into multi-agent orchestration and the broader “Agentic Enterprise” narrative. But platform capability does not automatically translate into partner capability. A tool can ship quickly. An SI operating model changes more slowly.

That gap is where customers are likely to get hurt.

AI-Powered Is Not the Same as Agentic

Mitul Patel drew the first line sharply: using AI tools in delivery can justify the label “AI-powered,” but only if AI is actually being used.

If an SI uses Claude, Codex, ChatGPT, or similar tools to accelerate development, documentation, analysis, or testing, she said, that is a legitimate claim. But she warned against repackaging simple automation or rules logic as AI. The issue is not only technical accuracy. It is trust.

For Mitul, a credible SI should be able to explain what AI is doing in language the customer understands. Not internal slang. Not opaque model talk. Not “we have AI in the backend” as a substitute for clarity. Her view is that clients, especially those under management pressure to “do AI,” need partners who can translate capability into business meaning.

Siddharth Sehgal approached the same question differently. He resisted a binary label. A firm is not suddenly agentic because it says so. AI, in his words, is still “a child, a baby that has been born and is crawling right now.”

That metaphor shaped his whole position. The point is not to pretend the child can run the bank. The point is to understand where it can safely help, how fast it is learning, and where human judgment still belongs.

For a bank, Siddharth said, the risk profile changes dramatically by use case. An AI support assistant explaining where to find a MICR code is different from an AI system making financial decisions or interpreting sensitive account activity. A customer may welcome the first and reject the second.

Kishore BT added a third lens: the platform owner’s view. If he were evaluating AI adoption for a major bank, he said, he would start with technology debt, planning horizons, platform choices, internal capability, subscription costs, and speed. The question is not merely whether an SI mentions AI. It is how much AI knowledge the customer and partner can absorb and apply effectively.

That is a more uncomfortable test for the consulting market. An AI-powered system integrator can show a slide. An agentic system integrator has to show operating discipline.

The First Land Grab Is for Trust

Robin Gupta pushed the panel on whether going agentic is a 12-month land grab or a capability firms should build slowly.

The answer depends on what, exactly, is being grabbed.

Mitul’s answer was the most direct. The next year, she argued, is a land grab for capability, credibility, and trust, not simply for the highest number of Agentforce implementations. Her warning was aimed at firms that equate becoming agentic with delivering Agentforce projects. That is too narrow.

“The mistake,” she said, is assuming that becoming agentic means “you are just implementing Agentforce.”

In Mitul’s framing, the deeper change is organizational. Consultants need to spot agent opportunities. Architects need to design agent systems. Delivery teams need to move from interface thinking to interaction thinking. Her most compact line captured the shift: “Whereas earlier you were designing screens, today you’re designing conversations.”

Siddharth agreed on urgency but resisted breadth for its own sake. His operating advice was almost product-founder-like: master a limited number of valuable use cases instead of attempting many unreliable ones. In his view, broad but weak AI adoption creates more risk than advantage. A firm that can solve one high-value agent scenario reliably may be more credible than a firm with 20 shallow demos.

Kishore’s concern was absorption speed. Salesforce and the AI ecosystem are releasing capabilities at a pace most teams struggle to track. Salesforce’s Summer ’26 announcement, for instance, emphasized multi-agent orchestration and agentic workflows across enterprise contexts. But knowing that these capabilities exist is not the same as knowing how to apply them inside a messy Salesforce org with old automations, inherited Apex, inconsistent metadata, and production data that behaves differently from a sandbox.

The practical implication for SI leaders is clear: the land grab is not for logos. It is for reusable knowledge, trust patterns, governance muscle, and the right to keep advising customers as the technology keeps shifting.

An Agent Changes the Definition of Done

Traditional Salesforce delivery has a familiar grammar. A statement of work names flows, validation rules, Apex classes, Lightning Web Components, integrations, reports, permissions, and environments. Testing then checks whether the agreed functionality behaves as expected.

Agents disturb that grammar.

A flow either follows its path or fails. An AI agent reasons across language, context, data, prompts, actions, and guardrails. It may answer the same question differently depending on phrasing, data state, knowledge freshness, permissions, or surrounding conversation. That does not make sign-off impossible. It makes the old sign-off model incomplete.

Mitul argued that agentic projects should not be validated by trying to prove every response will be identical. Instead, teams should test whether the agent operates inside acceptable boundaries. Her example was a customer service agent that resolves most defined queries correctly and escalates the rest. A 95% figure came up as an illustration, not a universal benchmark. The real point was that success becomes boundary-based and scenario-based.

Siddharth made the SOW implication explicit. A traditional scope might say the partner will build three flows, two validation rules, five triggers, and several classes. An agentic scope, he argued, should instead define the scenarios the agent must handle. For example: here are 100 customer support scenarios; if the agent successfully handles an agreed percentage and escalates appropriately, the first phase is accepted.

That is a different commercial object.

The deliverable is not just code. It is an operating capability with measured behavior.

Kishore added the implementation reality underneath that model. Agents can generate systems, but generated output is not production-ready by default. Prompt context, documentation, source-code awareness, existing metadata, validation, and testing all affect quality. An agent that creates new classes instead of reusing existing assets can add technical debt while appearing productive.

For customers, the lesson is blunt: do not sign an agentic statement of work that only lists build artifacts. Ask for scenarios, data assumptions, prohibited actions, escalation rules, policy constraints, testing methods, human review points, and post-launch monitoring responsibilities.

Go-Live Becomes the Beginning

In traditional SI culture, deployment often marks the psychological finish line. The team goes live, celebrates, stabilizes, and moves toward closure.

The panel’s view of agents was different.

Mitul compared agents to new employees. You train them, monitor their performance, review their work, gather feedback, refine behavior, and give them more responsibility over time. “Go-live is really the beginning of an optimization cycle when it comes to an AI agent,” she said.

Siddharth reached a similar conclusion from the product side. If his team changes a product UI or releases new documentation and the support agent does not learn it, the agent effectively becomes obsolete. It may still respond confidently, but it is answering from the past.

That matters for Salesforce managed services. Agentic delivery naturally creates ongoing work: prompt refinement, knowledge-base updates, scenario expansion, regression testing, guardrail tuning, documentation refreshes, escalation analysis, and response-quality review. This could become a major commercial opportunity for Salesforce SI firms.

It also creates a scope trap.

If contracts do not define who owns agent monitoring, knowledge updates, release adaptation, and failure review, the SI and client may both assume the other side is responsible. A traditional hypercare period will not be enough for a system whose performance depends on changing data, changing policy, changing product behavior, and changing customer questions.

Salesforce’s own Trailhead guidance on Agentforce guardrails makes a related point: some guardrails live in technology, but governance outside the technology matters too. That aligns closely with the panel’s message. An agent is not governed only by configuration. It is governed by an operating process.

Billable Hours Are Under Pressure

The most commercially charged part of the discussion came when Robin asked where SI margins go if agents compress delivery time.

The panel broadly agreed on one thing: traditional implementation hours will decline.

They differed on what replaces them.

Mitul argued that agentic SIs do not necessarily earn less. They earn differently. “The margin is gonna move from execution to expertise,” she said. Her thesis is that customers never really wanted hours; they wanted business outcomes. AI simply exposes the mismatch between effort-based pricing and outcome-based value.

She compared the shift to cloud and low-code. Cloud reduced infrastructure work but created new consulting categories. Low-code reduced some coding effort but increased demand for business process transformation. In her view, agentic AI will follow a similar pattern: less revenue from manual execution, more value in advising, designing, governing, optimizing, and helping clients solve the next business problem faster.

Siddharth was less optimistic about the smoothness of that transition. He agreed hours will compress, but warned that clients will not pay old estimates when AI makes the work faster. His example was direct: if a project once took 200 hours and now takes 50, the customer can use Claude or another tool to challenge the estimate. Inflated services pricing becomes easier to detect.

He did see a counterweight. Reduced cost may unlock projects that were previously unaffordable or indefinitely postponed. Inside his own company, he said, ideas that had been sitting for years became feasible once agents reduced the effort required to build them. In that version of the market, SIs lose hours per project but gain volume.

Kishore went further. Asked whether billable hours continue, he answered: “It’s 100% discontinued.” His view was that customers will use AI to negotiate estimates downward, and SIs will need to protect value elsewhere: finding technical debt, identifying gaps in the org, improving architecture, and deepening customer relationships.

This is not a contradiction so much as a spectrum of confidence.

Mitul sees value migrating toward expertise and outcomes. Siddharth sees real revenue pressure offset by more total demand. Kishore sees the old billable-hours model breaking more decisively and pushes SIs toward technical debt, governance, and relationship depth.

For SI founders, the strategic question is not whether AI destroys services revenue. It is whether the firm can stop depending on inefficiency as a margin source.

The Biggest Risk Is Not a Visible Failure

Salesforce teams know how traditional automation fails. A validation rule blocks a transaction. A flow throws an error. An Apex exception surfaces. A regression test turns red.

Agents can fail more politely.

They may produce a fluent answer that sounds right, fits the tone, satisfies the user, and still violates policy, exposes data, invents a fact, applies the wrong discount, or relies on outdated documentation.

Robin sharpened this point by asking how enterprises can trust systems that may fail quietly. The panel’s examples showed why agentic testing is not merely a QA concern. It is a business risk discipline.

Siddharth described a discount scenario: if an agent is supposed to offer 8% but gives 72% after a persuasive customer interaction, the failure is not cosmetic. It could create financial damage, commercial inconsistency, and reputational fallout.

Kishore pointed to AI-generated development risk. If an agent writes new classes instead of reusing existing code, it may increase technical debt, slow the org, introduce security issues, and make future maintenance harder. The output may look productive while damaging the platform.

Mitul emphasized hallucination and policy drift. The new testing question is not only “does the workflow run?” It is “can we trust this agent?” That means testing for groundedness, sensitive-data exposure, tone, policy adherence, business-rule compliance, harmful actions, and escalation behavior.

Siddharth’s most memorable anecdote made the risk personal. After uploading family health reports to ChatGPT for trend analysis, he said the system flagged a cancer marker for his father. Alarmed, he took the report to a doctor, who found no such marker on the cited page. The model had fabricated the finding.

The anecdote should not be read as a medical claim. Its value is as a business warning: plausible falsehoods produce real reactions. In enterprise settings, the same pattern can trigger unnecessary escalations, bad decisions, compliance exposure, or customer panic.

External research supports the trust concern without needing to exaggerate it. Salesforce’s State of the AI Connected Customer report found that 61% of customers say trustworthiness becomes more important as companies adopt AI, while fewer than half trust businesses to use AI ethically. The same report found customers are much more cautious about AI agents making financial decisions or providing medical advice than handling lower-risk tasks.

That maps directly to Siddharth’s point: readiness is use-case-specific. No serious Agentforce implementation partner should treat all agent work as the same risk category.

Humans Remain Where Responsibility Ends

Could one agent supervise another agent?

Siddharth treated the question with humor, but the underlying issue is serious. Testing agents can help evaluate other agents. Evaluation workflows can generate adversarial questions, check responses, and flag risk. But an endless chain of agents reviewing agents cannot be the accountability model.

“Where does the buck stop?” he asked.

The panel’s answer was not that humans should sit around as emergency backup. Their role is more structural. Humans define acceptable risk. Humans decide which actions are prohibited. Humans approve production boundaries. Humans review severe failures. Humans investigate exceptions. Humans accept responsibility for the operating model.

Kishore’s position was especially clear on production readiness. Agents should be tested repeatedly, with realistic data variation, and reviewed by humans before higher-environment or production deployment. He stressed that sandbox, UAT, and production data can differ enough to expose failures that did not appear earlier.

NIST’s AI Risk Management Framework points in the same direction at a governance level. It frames AI risk management as a lifecycle activity involving design, development, use, evaluation, and ongoing management. For Agentic AI consulting, that lifecycle language matters. The risk does not end when the agent passes a demo.

This is where the definition of an Agentic SI firm becomes operational rather than decorative. A credible firm can say who reviews the agent, when, against what evidence, with what authority, and under which escalation process.

What Becoming an Agentic SI Actually Requires

By the end of the discussion, the strongest conclusion was not that every SI should race to become fully autonomous. It was that the old SI model is insufficient for agentic work.

A genuinely Agentic SI firm should be able to demonstrate real internal AI use, not only client-facing AI claims. It should explain its AI capability plainly. It should assess use-case suitability by industry, risk, data sensitivity, compliance exposure, and customer readiness. It should know when not to recommend an agent.

It should also change how it scopes work. A feature checklist is not enough. Agentic SOWs need scenarios, success-rate targets, escalation-rate expectations, prohibited actions, response-quality criteria, policy adherence requirements, realistic data assumptions, and post-launch responsibilities.

Testing must evolve as well. Traditional regression coverage still matters, but it is not sufficient. Agentforce testing and broader AI agent testing must examine whether the agent stays grounded, respects permissions, avoids sensitive-data leakage, uses current documentation, follows business rules, escalates correctly, and avoids harmful actions that look superficially reasonable.

The commercial model has to change too. If agents compress delivery hours, SIs cannot rely on old estimates dressed in new language. The defensible value moves toward expertise, architecture, risk management, technical-debt reduction, managed services, optimization, and business outcomes.

Finally, an agentic delivery model needs a clear human accountability layer. The organization may use agents to build, test, monitor, summarize, and recommend. But it still needs people to define policy, approve risk, and own consequences.

That may be the real dividing line between an AI-powered SI and an Agentic SI firm.

The winners will not simply be the Salesforce SI firms with the most agent demos, the fastest proposal language, or the loudest Agentforce implementation partner positioning. They will be the firms that can make agents useful enough to trust, measurable enough to manage, safe enough to deploy, and economically meaningful enough to change the consulting model itself.

Key Takeaways

• Becoming an Agentic SI firm means redesigning delivery, scope, testing, governance, support, and pricing around agents.

• AI-powered claims are credible only when the SI can explain how AI is used and where it creates business value.

• Agentic SOWs should define scenarios, success criteria, escalation rules, guardrails, and post-launch responsibilities.

• Billable implementation hours will likely compress; value must move toward expertise, outcomes, technical-debt reduction, and managed services.

• The hardest agent failures may be quiet: plausible, fluent, and wrong.

• Human accountability remains essential, even when agents help build, test, or monitor other agents.

FAQ

What is an Agentic SI firm?
An Agentic SI firm is a system integrator that redesigns its delivery model around AI agents, including discovery, design, development, testing, monitoring, support, governance, and commercial models.

How is an Agentic SI different from an AI-powered SI?
An AI-powered SI may use tools like ChatGPT, Claude, or Codex to accelerate work. An Agentic SI changes how the firm operates and how it delivers measurable, governed agent-based outcomes for clients.

How should Agentforce implementation projects be scoped?
They should be scoped around scenarios, success rates, escalation behavior, policy boundaries, prohibited actions, data assumptions, testing requirements, and post-go-live monitoring rather than only flows, classes, triggers, and hours.

Will AI agents reduce SI billable hours?
The panelists broadly expected implementation hours to decline. They differed on whether SIs can offset that decline through higher volume, value-based work, technical-debt remediation, managed services, and deeper advisory relationships.

Why does AI agent testing need to continue after go-live?
Agents depend on changing data, documentation, prompts, policies, releases, and user behavior. Continuous testing helps detect hallucinations, outdated answers, policy violations, escalation failures, and unsafe actions after deployment.