Enterprise Agent Use Cases That Work: Coding, Research, Data, Security, and IT Operations

Agents work where the loop closes. A task shape suits autonomous AI when two things are true: the agent can check its own work against an external verifier (a test suite, an executed query, a resolved alert), and the worst plausible action is recoverable (a rejected pull request, not a deleted production table). Rank enterprise agent investments by those two properties and the portfolio almost builds itself — coding first, suggestion-only review second, read-only research and analytics third, and act-on-infrastructure shapes last, behind approval gates.

This is why the honest map of production agent use cases is organized by task shape, not by vendor or industry. Anthropic's guidance on building agents makes the mechanism explicit for the strongest domain: coding works because "code solutions are verifiable through automated tests" and agents "can iterate on solutions using test results as feedback."^[1] Every other domain in this guide is best understood as a distance from that ideal: how good is the verifier, and who holds the blast radius.

What separates the shapes that work from the shapes that stall

Strip away the demos and the deployment stories cluster on a small set of structural properties. Working shapes have a machine-checkable definition of done: the tests pass, the query executes and reconciles, the alert is enriched with the evidence an analyst needed. Stalling shapes have a human-judgment definition of done (is this strategy memo *right*?), an unbounded action surface (arbitrary web or GUI actions), or a failure mode that is expensive to reverse. The same model, the same framework, and the same engineers produce a production system in one column and a permanent pilot in the other.

The task-shape map

These are the shapes that recur across enterprise deployments, ordered roughly by the strength of their feedback loop. Treat the grid as a coverage map for planning, not a scoreboard — adoption breadth varies by organization, and no adoption figures are implied.

Coding agents: the strongest domain, and why

Software development is where agents crossed from assistance to delegation, and the reason is structural. SWE-bench — the de facto scoreboard — is built from 2,294 problems drawn from real GitHub issues and their resolving pull requests across 12 popular Python repositories, with the repository's own test suite as the judge.^[2] That design mirrors the production deployment exactly: the agent edits files, runs the tests, reads the failures, and iterates. The verifier is not a rubric; it is the same gate human engineers ship through.

The production tooling has converged on the same anatomy. Anthropic's Claude Code is documented as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools," and it works directly with git — staging changes, writing commit messages, creating branches, and opening pull requests — with CI integrations for automated code review and issue triage.^[8] GitHub's Copilot coding agent runs each task in "its own ephemeral development environment, powered by GitHub Actions," where it can explore code, make changes, and execute automated tests and linters; sessions are capped at 59 minutes, and the developer reviews the diff and decides when a pull request is created.^[9] Cursor and Devin (from Cognition) compete in the same space; their capabilities are documented on their own product sites, outside this piece's primary-source scope, so evaluate them against the same criteria rather than on claims repeated here.

Notice what both first-party designs share: the agent acts inside a sandbox, the unit of output is a reviewable artifact (a branch, a draft PR), and the human checkpoint is one that already existed — code review. That is the pattern to copy into every other domain. What production deployments require beyond the tool is covered in depth elsewhere and only summarized here: an eval harness and tracing discipline (/guides/testing-and-debugging-agents), scoped credentials and spend controls (/guides/agent-governance-guide), and deliberate placement of approval gates (/guides/human-in-the-loop-agents).

Maturity read: production-grade, behind the PR gate. The failure mode that remains is not capability but reliability-per-attempt — which the review gate absorbs. Teams that weaken the gate to chase throughput reintroduce exactly the risk the artifact boundary was containing.

Code review and security scanning: the agent as second reviewer

Review agents are the lowest-risk agentic deployment in the enterprise because their entire action surface is a suggestion. GitHub's Copilot Autofix "automatically generates fix suggestions for CodeQL alerts on pull requests," covering a subset of queries across C#, C/C++, Go, Java/Kotlin, Swift, JavaScript/TypeScript, Python, Ruby, and Rust — and GitHub's own documentation is blunt that suggestions "require explicit developer review and acceptance," because a generated fix can fail to remediate the vulnerability or introduce a new one.^[6] That candor is the correct mental model for the whole category: treat the agent as a tireless reviewer with good recall and imperfect precision, never as an authority.

The same shape works from the model-vendor side. Anthropic ships a /security-review command in Claude Code and a GitHub Action that reviews pull requests with inline comments, checking for SQL injection, cross-site scripting, authentication and authorization flaws, insecure data handling, and dependency vulnerabilities; Anthropic reports using the tooling on its own production code, where it surfaced a remote code execution vulnerability (via DNS rebinding) and an SSRF flaw before they shipped.^[10] The economics are asymmetric: a false positive costs a reviewer minutes; a caught pre-production vulnerability saves an incident.

Maturity read: production-ready now, precisely because a human accepts every diff. The discipline to maintain is measurement — track accepted-suggestion rates and false-positive load per rule, or reviewer trust erodes silently and the comments get ignored.

Research agents: powerful, but the verifier is you

Deep-research agents are the first knowledge-work shape with real production presence, and the first where the feedback loop weakens. The architecture is documented most transparently in Anthropic's engineering write-up on its multi-agent Research system: a lead agent decomposes a query, parallel subagents search and read, and the system is evaluated on end state — "instead of judging whether the agent followed a specific process, evaluate whether it achieved the correct final state."^[4] On Anthropic's internal research eval, the multi-agent configuration outperformed a single-agent baseline by 90.2%.^[4] OpenAI's deep research documentation describes the same task shape from the API side: models (o3-deep-research and o4-mini-deep-research) that "find, analyze, and synthesize hundreds of sources to create a comprehensive report at the level of a research analyst," with inline citations to sources.^[11]

Why this works as a production use case despite the weak verifier: the task is read-only, so blast radius is negligible; the output is a draft, so the human checkpoint is natural; and citations make spot-verification cheap. Why it is not coding-grade: there is no automated test for *true*. A synthesis can be fluent, cited, and wrong in emphasis — and the failure surfaces later, in a decision. OpenAI's own documentation adds a second caution that enterprises underweight: research agents that browse the open web are exposed to prompt injection, where instructions smuggled into fetched pages can redirect the agent, including toward data exfiltration when it also holds access to internal sources.^[11] Treat web-browsing research agents as an untrusted-input pipeline and keep them credential-poor.

Maturity read: production for draft-quality synthesis with mandatory human review; not a system of record. Budget honestly — Anthropic reports multi-agent research runs consuming about 15× the tokens of a chat interaction,^[4] so this is a shape where per-task cost accounting matters from day one.

Data-analyst agents: natural language to SQL, with rails

NL-to-SQL is the most demanded agent shape outside engineering, because it attacks a real bottleneck: the queue between business questions and the analytics team. The first-party platforms now treat it as an agent problem, not an autocomplete problem. Google's Conversational Analytics API is explicitly framed as building a "data agent" that answers natural-language questions over BigQuery and Looker data, equipped with SQL, Python, and visualization tools, and steered by authored context — curated business definitions that guide behavior and improve accuracy.^[12] Amazon's Quick (the evolution of QuickSight) is described the same way: "you interact with Quick through natural language chat, and Quick uses AI agents to process your requests against connected data sources," with Quick Sight carrying the BI and dashboarding surface.^[13]

The task shape half-works, structurally. Generated SQL has a genuine verifier for syntax and schema — the query executes or it errors, and the agent can iterate on the error. It has no verifier for semantics: a query can run cleanly and answer a subtly different question than the one asked, and the person who asked is, by definition, not the person who can read the SQL. Google's own responsible-AI guidance states the risk plainly: output "can generate output that seems plausible but is factually incorrect," and Google recommends validating all output before use.^[12] The mitigations that separate working deployments from embarrassments are all governance-shaped: read-only scopes through existing role-based access control, a curated semantic layer so the agent joins the blessed tables, query logging for audit, and a visible show-the-SQL affordance so any analyst can check the work.

Maturity read: production within a governed perimeter — curated datasets, read-only credentials, semantic context — and demo-grade outside it. The build decision is less about the model and more about whether your semantic layer and access model are ready to receive an agent; the authorization patterns belong to the governance program (/guides/agent-governance-guide).

Data-engineering agents: schema drift, pipeline repair, quality checks

One layer down the stack, the same platforms are pointing agents at the pipelines themselves. Google's Gemini in BigQuery documentation describes AI-generated transformation recommendations for data preparation and a data engineering agent that "helps you build, modify, and troubleshoot data pipelines using natural language prompts."^[14] The task shape is friendlier than analytics in one respect: pipelines fail loudly. A broken transformation, a schema mismatch, or a failed load produces an error artifact the agent can read and iterate against — closer to the coding loop than to the analyst loop.

The blast radius, however, is the data itself, which is why the working pattern is propose-then-apply: the agent drafts the transformation or the repair, a data engineer reviews the diff, and changes ride the same review-and-deploy path as human-authored pipeline code. Auto-applied repairs belong only where the fix is reversible and the affected asset is non-critical. Maturity read: earlier than coding agents — assistive and accelerating, with the same first-party caveat as the analytics layer: validate output before use.^[12]

Security response agents: triage yes, containment carefully

Security operations is drowning in exactly the work agents are structurally good at: high-volume, evidence-gathering, summarization-heavy triage. Microsoft's Security Copilot — the most extensively documented first-party deployment — is positioned to "quickly triage complex security alerts into actionable summaries" with step-by-step response guidance, to generate KQL queries and analyze suspicious scripts from natural language, and to work embedded in Defender XDR, Sentinel, Intune, and Entra, with an ecosystem for building and adding agents; its documented flow ends with the analyst, who reviews and assesses each response.^[15]

Split the domain at the action boundary and the maturity picture is clean. Enrichment, correlation, summarization, and query generation are read-only, verifiable by the analyst in the normal flow of work, and deliver value immediately — this half is production-shaped today. Containment — isolating endpoints, disabling accounts, blocking traffic — is the highest-blast-radius action surface in this entire guide, and a wrong action is itself an availability incident. There is also an adversary in the loop: security agents consume attacker-influenced text (alerts, phishing content, log artifacts), which makes them a prime prompt-injection target — the same class of risk OpenAI documents for web-browsing research agents applies with higher stakes.^[11] Keep containment behind explicit human approval, with the checkpoint patterns from /guides/human-in-the-loop-agents, and expand agent authority only per playbook, starting with reversible actions.

Maturity read: assistive triage is production; autonomous containment is not. The right KPI is analyst time returned per alert and triage consistency — not headcount replaced.

IT operations agents: probabilistic diagnosis, deterministic remediation

The IT-ops shape that works in production is a division of labor, and AWS's tooling documents it end to end. On the diagnosis side, CloudWatch investigations is "a generative AI-powered assistant that can help you respond to incidents," scanning telemetry to surface related metrics, logs, deployment events, and root-cause hypotheses; the operator accepts or discards each suggestion, and every action the assistant takes is logged in CloudTrail for traceability.^[16] On the remediation side, the assistant does not free-form its way into production — it "might suggest that you use an Automation runbook to attempt to automatically resolve the issue."^[16]

Those runbooks are the deterministic half. Systems Manager Automation packages common maintenance and remediation tasks as predefined, parameterized runbooks that can be triggered by EventBridge events, configured to require approval by one or more users before executing, and rate-controlled — you specify how many resources to target concurrently and how many errors stop the automation, with input constraints (allowed values and patterns) bounding what the automation will accept.^[7] The architecture lesson generalizes beyond AWS: let the LLM do what it is good at (reading heterogeneous telemetry, forming hypotheses, drafting the incident narrative) and let audited, versioned, parameter-constrained automation do the touching of infrastructure, with the human approval step at the seam.

Maturity read: production, when composed this way. The anti-pattern is the inverse composition — an LLM with shell access to production. Auto-remediation without a human at the seam is defensible only for the classic low-risk, high-frequency incident classes (disk pressure, service restarts, certificate renewals) where the runbook is battle-tested and reversal is trivial.

The maturity table

What every production deployment requires

The per-domain sections above deliberately did not repeat the horizontal requirements, because they are the same seven times over and each has a full guide. Testing: agents need layered evaluation — deterministic mocked-tool tests, sandboxed simulation, graded evals from real usage — plus tracing that can reconstruct any run; Anthropic's blunt version is "we recommend extensive testing in sandboxed environments, along with the appropriate guardrails."^[1] That discipline, including the reliability framing vendors should be held to, is /guides/testing-and-debugging-agents. Governance: agent identity, scoped least-privilege credentials, spend controls, and audit trails are /guides/agent-governance-guide. And checkpoint design — where a human approves, on what artifact, at what volume — is /guides/human-in-the-loop-agents.

Honest objections

"The benchmark numbers oversell it." Partly true, and the fine print matters: the 77.2% headline is on the human-validated 500-problem Verified subset, averaged over 10 trials, with scaffolding disclosed — and vendors' quoted scores move with subset, trials, and test-time compute.^[3] More importantly, benchmarks measure peak per-attempt capability, while production cares about consistency: τ-bench's pass^8 falling below 25% in its retail domain is the cleaner predictor of what an unattended agent does across a thousand daily runs.^[5] The conclusion is not to dismiss the numbers — it is to design so a verifier or a reviewer filters the inconsistent attempts, which is exactly what the working shapes do.

"Outside these shapes, agents still fail at ordinary work." Correct, and worth stating plainly: on WebArena's realistic open-ended web tasks, the best GPT-4-based agent at publication achieved a 14.41% end-to-end success rate against a human baseline of 78.24%.^[17] Models have improved since, but the structural lesson stands — open-ended GUI and web autonomy lacks both the verifier and the bounded action surface that the seven shapes in this guide have, which is why it remains demo-rich and deployment-poor. Fund the shapes with closed loops; pilot the rest with skepticism.

"The quiet failures are the expensive ones." Yes. A coding agent's failure is loud (red CI); an analytics agent's failure is silent (a plausible wrong number in a board deck). This is why the vendors themselves hedge — Google instructs customers to validate all output from its early-stage Gemini cloud products before use^[12] — and why the semantic-verification gap in NL-to-SQL deserves more engineering investment than the model choice. Where the verifier is weak, spend on the checkpoint. And agent economics are real: at roughly 15× chat-level token consumption for multi-agent research runs,^[4] a use case must clear a real per-task value bar, not just a feasibility bar.

The read

For a CIO, CTO, or platform lead, this maps to a sequencing decision, not a vendor decision. Deploy in order of loop strength: coding agents behind the PR gate and review agents on every repository first — they ride governance you already have. Then research agents for draft synthesis with review, and NL-to-SQL inside a governed semantic perimeter. Then the ops shapes — SOC triage and IT incident investigation — composed as probabilistic diagnosis over deterministic, approval-gated action. Hold autonomous containment and open-ended computer use in R&D. Across all of them, the portable insight is the same one the strongest domain teaches: agents don't succeed because models got smart; they succeed where someone engineered a loop that catches them when they aren't.