For the past eighteen months, "AI in GRC" has mostly meant a chat box bolted onto an existing dashboard: ask a question about a risk register, get a summarized answer; ask for a first draft of a policy, get one back. Useful, but not fundamentally different from what a well-built search or reporting feature already did. What changed in September 2026 is the scope of what vendors are now shipping under the same "agentic" label. Diligent's announcement at Gartner's Enterprise Risk, Audit and Compliance (ERAC) conference in Dallas — an Orchestration Agent that routes natural-language requests to specialized agents, a Risk Management Agent that monitors risk data and flags emerging risks continuously, and an Internal Audit Agent that maps risks to audit objectives and supports evidence collection — describes agents that are meant to do parts of the actual risk work, not just answer questions about it.
Diligent is not alone, and this piece isn't really about Diligent. It's the most recent, most public example of a shift every GRC, audit, and enterprise-risk platform vendor is racing toward at the same time, for the same reason: Gartner has projected that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from under 5% in 2025 — an eight-fold jump in about eighteen months, with agentic AI potentially representing close to a third of enterprise application software revenue by the mid-2030s. Every platform an internal audit, compliance, or enterprise-risk function already runs is under commercial pressure to ship an "agent" this year, whether or not what ships actually behaves like one. That gap between the label and the behavior is exactly what a risk or audit leader now has to learn to test for.
This connects directly to two questions Crest.Digital's Agentic Risk & Continuous Assurance practice has already worked through: who is accountable for an AI agent's decision, and why AI agents need audit trails. What the current platform wave adds is a market-wide test case for a third question — not whether an agent can be governed, but whether it does anything at all beyond describe data faster.
Crest.Digital's Agentic Risk & Continuous Assurance practice builds agentic execution — reading source systems, testing controls, investigating exceptions, and closing the loop with audit-ready evidence — around the systems you already run, not a generic template built for a vendor's broadest customer base.
Explore Agentic GRCThe GRC Platform AI Wave
Diligent's announcement is worth reading in detail because of how deliberately it moves past the summarization layer. The Orchestration Agent gives GRC staff a natural-language interface for coordinating audit and risk work — describe what needs doing, and it routes the task to the right specialized agent rather than requiring a person to navigate module by module. The Risk Management Agent operates inside enterprise risk management to monitor risk data, clean and refine records, coordinate assessments, follow up on overdue actions, and identify emerging risks, explicitly aimed at moving teams from periodic to continuous oversight. The Internal Audit Agent works inside the audit module to identify relevant risks, map them to audit objectives, link controls, and support evidence collection and findings development. Underpinning all three is what Diligent calls a "GRC brain" — a connected intelligence layer linking regulations, obligations, policies, controls, risks, and evidence, with select integrations planned for October 2026.
Andrew Amos, Diligent's VP for APAC, was careful to frame the launch in governance terms rather than autonomy terms: "This isn't about handing responsibility to AI. It's about using AI to help teams make faster, better-informed decisions, while ensuring strong governance through human judgement, clear accountability, and understanding how decisions and recommendations are reached." That framing matters, and it's consistent with how Crest.Digital has positioned agentic execution across this series — the agent does the reading, testing, and drafting; a named human still owns the decision.
For a risk or audit leader, the significance of any single vendor's launch is secondary to what it confirms about the direction of the entire market: GRC, audit, and enterprise-risk platforms are converging on agent-based execution as the next competitive battleground, on a timeline measured in months rather than years. That convergence is exactly what makes the next question — how to tell a genuine agent from a well-marketed assistant — the one worth getting right before the next renewal cycle, whichever platform an organization already runs.
Agent, or Agentwashing?
Gartner's own research gives the phenomenon a name, and it's a useful one to bring into every platform evaluation from here forward: "agentwashing" — labeling an AI assistant as an autonomous agent when it still depends on continuous human prompting for every step. Anushree Verma, Gartner's Sr Director Analyst covering the space, has described the trajectory as agents evolving "from task and application specific agents to agentic ecosystems," transforming enterprise applications "from tools supporting individual productivity into platforms enabling seamless autonomous collaboration." That's the destination. The immediate risk, given the commercial pressure behind the 40%-by-2026 figure, is that a large share of what ships in the next twelve months will carry the label without the substance.
Gartner's own working distinction is useful precisely because it's simple: a true agent performs a complex, autonomous, end-to-end task without requiring human intervention at each step; an assistant depends on continuous user input to move forward. Applied to a GRC platform's marketing page, the test isn't "does it use the word agent" — it's "if I remove this feature, does a task that a person used to do disappear, or does only a shortcut to information a person could already find disappear." A summarization feature that turns a 40-page policy into a one-paragraph brief is useful and saves time; it is not execution. An agent that reads the policy, converts it into testable obligations and controls, checks whether evidence exists for each one, and flags the gaps to a named control owner is execution, whether or not the vendor uses the word "agent" to describe it.
This is not an argument against adopting platform-native AI agents where they genuinely execute a task well. It's an argument for evaluating every vendor claim against a specific, named workflow — not the vendor's own terminology — and for insisting on a demonstration against the buyer's own data and control language before committing a renewal cycle or a budget line to it. ISACA's 2026 guidance on securing AI agents makes a parallel point from the security side: an agent's identity, permissions, and action log need the same governance rigor as a human user's, regardless of how the vendor markets its autonomy. Boards and audit committees are increasingly the audience for these claims too; a committee that hears "our GRC platform now has AI agents" deserves a follow-up question about which specific tasks those agents complete without a human doing each step, not just whether the vendor used the word.
Crest.Digital's agents connect to the systems you already run — GRC platform, ERP, procurement, identity, vendor and TPRM tools — and execute the full chain: read, test, detect, recommend, assign, follow up, and evidence closure, with a named human decision at every judgment point.
What Agentic Execution Actually Looks Like Across the Risk Lifecycle
Crest.Digital's own answer to the "is this execution or narration" question is a specific chain, applied consistently across every use case in the Agentic Risk & Continuous Assurance practice, from continuous controls monitoring to policy-to-control intelligence to issues and remediation: Read → Understand → Test → Detect Exception → Recommend → Assign Action → Follow Up → Evidence Closure. A platform feature that only performs the first two or three links in that chain — reading a document, summarizing it, answering a question about it — is a capable assistant. A platform feature, whether built by a GRC vendor or by a customized layer sitting across several systems, that carries a task all the way through detection, a recommendation, an assigned and tracked action, and an audit-ready evidence record at closure is execution.
The distinction is not academic for a risk or audit function evaluating where to invest next. A vendor's native agent that stops at "detect exception" and hands a raw alert to a generic queue still leaves the organization doing the highest-value, most judgment-dependent work manually — deciding who owns it, what to recommend, how urgent it is, and whether it closed properly. An execution layer that carries the exception through recommendation, named ownership, follow-up, and evidenced closure removes that manual burden at the point where it actually costs the organization time and creates the audit gaps that show up as repeat findings. The chain is also what makes an agent's output defensible to an external auditor or regulator: a recommendation with no record of who acted on it and when is not meaningfully different from a manual process with worse documentation.
This is also where cross-system coverage matters more than any single platform's own agent roadmap. A GRC platform's native agents, however capable, generally operate inside that platform's own data model. A vendor-master change that also affects a procurement control, an access grant that also touches a SOX-scoped financial application, or a sanctions hit that also connects to a contract renewal sitting in a separate TPRM tool — these cross-system exceptions are exactly the ones a single-platform agent is structurally unlikely to catch, and exactly the ones that produce the highest-consequence audit findings when they're missed. An execution layer built to connect across the systems an organization actually runs, rather than deepen inside one vendor's own model, closes that specific gap.
An 8-Point Framework for Evaluating and Building Agentic Execution
Whether an organization is evaluating a platform vendor's new AI agents, building a customized execution layer, or both, the same eight points establish where genuine execution exists today and where a chat layer is being mistaken for it.
Task-Level Capability Mapping
List the specific risk, audit, and compliance tasks a proposed agent claims to handle, and test each one individually against the read-understand-test-detect-recommend-assign-follow up-evidence chain.
Cross-System Reach
Identify which of the agent's tasks require data or actions outside its native platform, and confirm whether it connects to those systems or stops at the platform's own boundary.
Exception Detection Depth
Test whether the agent surfaces exceptions with a root-cause hypothesis and supporting evidence, or only a bare anomaly flag that still requires a human to investigate from scratch.
Named Ownership on Every Assigned Action
Confirm that every recommendation the agent generates is assigned to a specific accountable individual, not a generic team queue that diffuses responsibility.
Follow-Up and Escalation Logic
Verify the agent tracks overdue actions, escalates them on a defined timeline, and does so without silently closing or downgrading items that remain unresolved.
Evidence Closure, Not Status Change
Test whether closing an item requires evidence that the underlying condition was actually fixed, or only a status field being changed by whoever is assigned to it.
Explainability at the Recommendation Layer
Require the agent to show its reasoning and the source data behind each recommendation, not just the recommendation itself, so a reviewer can validate rather than simply trust it.
Human Approval Points, Explicitly Defined
Map exactly where in the chain a human decision is required before the agent's output becomes an action, and confirm that boundary is enforced in the workflow, not left to individual discretion.
Points one and two do most of the diagnostic work in a vendor evaluation: an agent that fails the task-level capability test, or that only reaches as far as its own platform's data, is not going to close the gaps that produce an organization's most expensive audit findings, however well it's marketed.
Building the Execution Layer: A Six-Step Delivery Playbook
Crest.Digital delivers agentic execution as a configurable "Risk Automation Pod" rather than a bespoke software build or a single platform's built-in feature set — a reusable stack of integration connectors, an agent orchestration layer, a workflow and approval-routing engine, a rules and risk-scoring engine, and an evidence repository, customized around the specific workflows, systems, and exceptions an organization needs covered first.
The Discover → Design → Connect → Deploy → Validate → Transfer Model
- Discover: Map the specific risk, audit, or compliance workflows worth automating, the systems and data behind each one, and where a generic platform agent's coverage already ends.
- Design: Define the agent chain for each workflow — read, understand, test, detect exception, recommend, assign action, follow up, evidence closure — and the specific human approval points within it.
- Connect: Integrate with the GRC platform, ERP, procurement, identity, and vendor systems that supply source data, so the execution layer works across systems rather than inside one vendor's data model.
- Deploy: Implement the customized agent chain for the selected workflows, routing every detected exception to a named accountable owner rather than a generic queue.
- Validate: Run parallel testing against the existing manual or platform-native process, confirm the agentic layer catches what human review would have found, and calibrate accuracy thresholds before scaling.
- Transfer or manage: Hand the execution layer to the risk, audit, or compliance function to operate, or continue it as a Crest.Digital-managed service as workflows and underlying systems evolve.
Starting with the one or two workflows that already generate the most manual follow-up — overdue remediation actions, vendor-master exceptions, access recertification — gives the validate step the clearest before-and-after comparison and builds the evidence base an audit committee will look for before approving wider rollout.
Inside the Process, Not Beside It
The distinction this piece has drawn between a chat layer and genuine execution has a direct implication for how an organization should think about building or buying agentic capability: an AI feature added beside an existing GRC or audit process — a separate chatbot window, a "co-pilot" panel that answers questions about data the process already produced — leaves the process itself unchanged and still dependent on the same manual steps it always had. An agent built inside the process, executing specific links in the read-through-evidence chain and handing off only the judgment calls a human genuinely needs to make, changes what the process actually requires of the people running it.
This is also why Crest.Digital's own agents are built customized to each client's systems, control language, and risk taxonomy rather than shipped as a single fixed product. Even though the client-facing solution is customized, the underlying stack — integration connectors, agent orchestration, the workflow and approval engine, the rules and risk-scoring engine, the evidence repository, the issues and remediation module, AI logs and explainability, role-based access, dashboards, and audit trails — is reusable across engagements. The client-specific portion is data mapping, control logic, workflow definitions, and dashboards, not a rebuild of the entire technology stack from scratch. That's the practical answer to a fair question any CFO or CAE should ask before commissioning custom AI work: why isn't this just another bespoke software project with the usual cost and timeline risk. It is a configurable framework applied to a specific environment, not a one-off build.
None of this argues against a GRC platform's own native agents where they genuinely execute a task well — Diligent's Internal Audit Agent, for instance, doing evidence-collection support inside a workflow the platform already owns end-to-end, is a legitimate example of execution rather than agentwashing, on the evidence available so far. The argument is narrower and more durable than any single vendor's roadmap: apply the same execution test — does removing this feature remove a task, or only a shortcut — to every AI claim a platform makes, buy or build the pieces that pass it, and build the cross-system execution layer for the workflows and exceptions no single platform's agents are structurally positioned to reach.
This connects directly to earlier work in Crest's Agentic Risk & Continuous Assurance series: the accountability question in who is accountable for an AI agent's decision, the evidentiary discipline in why AI agents need audit trails, and the distribution problem covered in the real audit gap isn't detection, it's distribution. An agent that executes well but can't explain its reasoning fails the first; an agent that executes well but leaves no evidence trail fails the second; and an agent that executes well in isolation but never reaches the business-unit owner who can act on it fails the third. Genuine agentic execution has to clear all three, not just the capability bar the marketing page implies. It also has to hold up against the standards internal audit and risk functions are already assessed on — the IIA's Global Internal Audit Standards and COSO's Internal Control-Integrated Framework both require evaluating the adequacy of governance and control design, not simply whether a vendor's feature list includes the word "agent."
Crest Perspective
AI governance programmes that treat AI risk as a technology problem will be underprepared for the regulatory environment taking shape in 2025–26. The EU AI Act, NIST AI RMF, and emerging FCA guidance all frame AI risk as a governance and accountability question first — the technology controls follow from having clear answers to who is responsible, what decisions the AI influences, and what the escalation path is when the system behaves unexpectedly.
Frequently Asked Questions
At Gartner's Enterprise Risk, Audit and Compliance Conference in September 2026, Diligent unveiled new agentic capabilities for its Diligent One platform: an Orchestration Agent that lets GRC staff coordinate audit and risk work through natural language, a Risk Management Agent that monitors risk data and identifies emerging risks continuously, and an Internal Audit Agent that maps risks to audit objectives and supports evidence collection. This is not full autonomy. Diligent's own leadership was explicit that the goal is faster, better-informed human decisions under strong governance, not handing responsibility to AI. It is, however, a clear signal that GRC platforms are moving from systems that record risk data to systems that actively perform parts of the risk work.
A copilot, chat layer, or "ask AI" feature answers questions about data that already exists in the platform: it summarizes a report, drafts a paragraph, or explains a chart. Genuine agentic execution goes further along the actual risk lifecycle: it reads source documents and system data, tests conditions against defined rules, detects and investigates exceptions, generates a recommendation, assigns and tracks the resulting action to a named owner, and closes the loop with evidence that stands up to audit. The practical test is whether removing the AI feature would remove a task a person used to do, or only remove a shortcut to information a person could already see.
Agentwashing is Gartner's term for labeling an AI assistant as an autonomous agent when it actually still depends on continuous human prompting for every step. Gartner has projected that task-specific AI agents will appear in 40% of enterprise applications by the end of 2026, up from under 5% in 2025 — an eight-fold jump in about eighteen months — which creates strong commercial incentive for vendors to attach the word "agent" to features that do not meet the bar. For risk and audit leaders, the practical implication is to evaluate any GRC platform's AI claims against a specific end-to-end task (does it complete a defined piece of risk work without a human doing each step) rather than against the vendor's own terminology, and to require a demonstration on the buyer's own data before committing budget.
No, for two structural reasons. First, most enterprises run risk, audit, and compliance work across several systems — a GRC platform, an ERP, procurement and payroll systems, identity and access tools, vendor and TPRM platforms — and a single vendor's agents typically operate only inside that vendor's own data model, leaving the cross-system exceptions (a vendor-master change that also touches a procurement control, an access grant that also affects a SOX-scoped application) uncovered. Second, a platform vendor's agents are built to a generic template that fits its broadest customer base, not to a specific organization's control language, risk taxonomy, or approval hierarchy. A configurable, customized execution layer that sits across the systems an organization actually runs closes both gaps without requiring a platform migration.
No. Crest.Digital's Agentic Risk & Continuous Assurance practice does not replace a company's GRC platform, ERP, or system of record — it builds a customized execution layer that connects to those systems, executes the full risk chain (read, understand, test, detect, recommend, assign, follow up, evidence) across whichever tools an organization actually runs, and hands off audit-ready evidence rather than another dashboard. Where a platform's own native agents cover a specific workflow well, Crest's layer extends coverage to the systems and exceptions that platform doesn't reach, rather than competing for the same seat.
For how these agents sit alongside vendor risk and voice follow-up, see agentic GRC, Voice AI and the TPRM platform.