Applications
Where autonomous agents could help, and where they should not act alone.
Six conceptual scenarios. None is a product or a case study. Each shows how a workflow would pass through the reference model, and where a person remains responsible.
Software Engineering
Agents that inspect a codebase, analyze an issue, propose changes, and run permitted tests.
Problem
A team needs to upgrade a library across a service with uneven test coverage. Finding every usage, reading the upgrade notes and making consistent edits is slow, repetitive work that pulls engineers away from design decisions.
Example workflow
- Interpret the goal and define criteria: build passes, tests pass, changes stay in scope.
- Plan: locate usages, read upgrade notes, change the code in stages.
- Select code search, an editor and the test runner, working on a branch.
- Apply changes and run the permitted tests in a sandbox.
- Verify test results, type checks and that the diff stays within scope.
- Pause for a person to review the proposed change.
Potential benefits
- Offloads repetitive investigation and mechanical edits.
- Shortens the path to a change a person can actually review.
Required permissions
- Read access to the repository.
- Write access limited to a working branch.
- Permission to run a defined test command in a sandbox.
Risks and limitations
- Weak tests give false confidence.
- Architectural judgement stays with engineers.
- It must never merge or deploy on its own.
Verification approach
Existing and added tests, type checks and linting, plus an automated check that the diff only touches the intended scope. A human reviewer approves before anything is merged.
Research and Knowledge Work
Agents that gather information, compare sources, and produce structured summaries.
Problem
An analyst needs a structured comparison of several approaches to a technical problem, with sources. Collecting material, tracking where each claim came from and spotting conflicts consumes most of the time that should go to judgement.
Example workflow
- Interpret the question and define what a good answer includes.
- Plan sub-questions to answer.
- Retrieve material from approved sources.
- Extract claims and record where each one came from.
- Cross-check claims across sources and flag conflicts.
- Pause for a person to review conclusions and citations.
Potential benefits
- Broader first-pass coverage with consistent source tracking.
- Analyst time shifts from collecting to judging.
Required permissions
- Read-only access to approved document stores and search.
- A scratch note store scoped to the task.
Risks and limitations
- Sources can be misread or over-weighted.
- A claim cannot be confirmed beyond what its sources support.
- Licence and copyright limits apply to source material.
Verification approach
Every claim is linked to a passage and checked against it. Conflicts between sources are surfaced rather than smoothed over, and a person reviews the conclusions.
Data Analysis
Agents that examine datasets, execute approved analyses, and report findings.
Problem
A team wants to understand why a metric changed between two periods, using a dataset it owns. The analysis is a sequence of queries and calculations that is easy to do inconsistently and hard to reproduce afterward.
Example workflow
- Define the question and what evidence would answer it.
- Plan the analyses to run.
- Select a query engine and analysis libraries.
- Run read-only queries and calculations.
- Verify: recompute key figures independently, reconcile totals, run sanity checks.
- Pause for a person to review the interpretation.
Potential benefits
- Systematic exploration with a recorded trail.
- Calculations that can be reproduced.
Required permissions
- Read-only access to the specific dataset.
- An analysis runtime with no outbound network access.
Risks and limitations
- Correlation versus causation remains a human judgement.
- Biased or incomplete data yields confident-looking errors.
- Metric definitions must be unambiguous.
Verification approach
Key figures are recomputed by an independent method, totals are reconciled, and the code and queries used are stored so a reviewer can rerun them.
Technical Operations
Agents that assist with diagnosis, predefined operational procedures, and controlled execution.
Problem
An alert fires for elevated error rates on a service. The on-call engineer wants the first diagnostic pass assembled before they join, instead of starting from a blank terminal.
Example workflow
- Interpret the alert and its scope.
- Plan diagnostic steps from the relevant runbook.
- Select read-only observability tools.
- Gather and correlate logs, metrics and recent deploys.
- Verify: rank hypotheses with evidence and state what is uncertain.
- Any remedial action waits for a person.
Potential benefits
- Evidence assembled sooner, runbooks followed consistently.
- Engineers start with context rather than from scratch.
Required permissions
- Read-only access to logs, metrics and deploy history.
- Read access to runbooks. No write access to production systems.
Risks and limitations
- Remediation on production is high-consequence and stays gated.
- It cannot see what is not instrumented.
Verification approach
Each hypothesis cites the specific evidence behind it. Proposed remediation steps are presented for approval with the evidence attached, and nothing is executed without it.
Business Process Execution
Agents that coordinate repetitive, rules-based tasks across authorized systems.
Potential benefits
- Fewer manual handoffs and a more consistent process.
- A clear audit trail of what was done and why.
Required permissions
- Scoped, per-system credentials for only the steps required.
- No standing access. Credentials expire with the task.
Risks and limitations
- Policy exceptions need people.
- Errors can propagate across systems.
- Financial and legal actions remain approval-gated.
Verification approach
Records are compared across systems after each run, mismatches are reported rather than silently corrected, and approval requests include the evidence needed to decide.
Problem
A routine request, such as onboarding a vendor, spans a form, a records system, an email thread and an approval step. Each handoff between systems is a place where information is retyped, delayed or lost.
Example workflow
- Interpret the request and the governing policy.
- Plan the sequence across systems.
- Select the right tool for each system, with scoped credentials.
- Perform the steps and record state after each.
- Verify that records agree across systems.
- Steps with financial or legal effect wait for a person.
Developer Tooling
Agents that connect development workflows with approved APIs and utilities.
Problem
A platform team wants an assistant inside its toolchain that can scaffold services, run checks and answer questions about internal conventions. Today that knowledge lives in wikis and in a few people’s heads.
Example workflow
- Interpret the request in its developer context.
- Plan: gather conventions, generate a scaffold, run linters.
- Select templates, the repository and CI interfaces.
- Execute in a sandbox.
- Verify lint, tests and CI status.
- Pause for a person to review the generated change.
Potential benefits
- More consistent setup, with conventions encoded as checks.
- Less time spent hunting for how things are done locally.
Required permissions
- Read access to templates and documentation.
- Branch-scoped write access and permission to trigger CI.
Risks and limitations
- Conventions change, so tool descriptions must be maintained.
- Generated code needs review.
- Quality depends on the tests and descriptions it is given.
Verification approach
Linters, tests and CI results gate the change, and an evaluation set of representative tasks is rerun whenever the tool descriptions change.
What all six require
Common requirements, whatever the task.
- Permissions scoped to the task, expiring with it.
- Acceptance criteria written before the work starts.
- Verification that produces evidence a reviewer can inspect.
- A named person who approves consequential steps.
- Limits on cost and time, and a way to stop the run.
- A log of what was planned, called and decided.
Fit check
Is your task a good candidate?
Five questions to ask before anyone delegates a workflow to an agent.
- Can "done" be written as criteria someone could check?
- Are the actions reversible, or can they be staged for approval?
- Do the tools involved expose reliable, scoped interfaces?
- What does a wrong action cost, and who bears it?
- Can a person review the result at a reasonable cost?
If the answer to the first or the last is no, the task is probably not ready for an agent. If the second or the fourth looks unfavourable, keep a human approval step.
Contact
Discuss whether your task fits.
Describe the workflow, the systems involved and what a wrong action would cost. We will think it through with you.