What AI Agents Can Do Now: From Errands to Real Work
A grounded tour of what AI agents can already do in research, coding, operations, customer support, and personal workflows.
The easiest way to misunderstand AI agents is to imagine one general robot clerk doing everything. Useful agents usually work within a narrower workflow: they have a task, access to particular tools, and a way to report what they did or ask for help.
An agent might gather sources for a brief, propose a code change, or prepare a customer reply. Whether it can do any of those things depends on the product, its integrations, the information available, and the permissions it has been given. A polished answer is not proof that it checked a source or completed an action. The guide to how agents work explains the tools and controls behind the result.
Research that ends with a usable answer
A normal search session leaves you with tabs. An agent with web access can search, read available sources, compare dates, summarize disagreements, and organize a brief around a decision. This can help with vendor comparisons, technical surveys, policy research, travel planning, and competitive monitoring.
For example, ask for a comparison of three vendors using their current pricing and documentation, with links, publication or access dates, and a list of missing information. Check the cited pages: a link may be broken, a price may apply to a different plan, and a summary may miss a qualification. For a consequential decision, verify the underlying sources and involve someone with relevant expertise. The time saved depends on the task and the review required.
Coding with a working memory
Software development has a natural loop: inspect files, make a change, run a test, read the result, and revise. A coding agent with repository and command access can investigate a bug, propose a patch, add or update tests, and explain the diff. GitHub documents an example in which its Copilot agent can work on an assigned issue and request review of a pull request.
Give the agent a bounded task, such as fixing a reproducible error in one module, and ask for the changed files, test results, and any tests it could not run. A passing test does not prove a patch is correct or secure. A developer still needs to review the diff, assess the tests and side effects, and decide whether to merge or deploy. The coding agent onboarding guide covers the context and boundaries that help this work.
Customer operations
A support agent with access to the right records can read a ticket, look up order status and policy, draft a reply, and suggest when to escalate. A sales agent might research an account and prepare a follow-up. These are possible workflow designs, not guarantees that every product can access every system or handle every case.
A useful first assignment is to draft delivery-status replies for human review. The output should identify the order and policy information used, note missing facts, and stop if the records conflict. A person checks the draft before it is sent; refunds, policy exceptions, and account changes need their own authorization. The workplace guide describes how to assess a pilot, including review time and failed runs.
Office work between systems
Much office work consists of handoffs: find a document, compare a spreadsheet, update a record, create a ticket, and notify an owner. An agent can help connect those steps when the necessary systems are available to it. It might compare meeting notes with a project board and prepare proposed tasks, including the source for each one.
The difficult part is deciding which record is authoritative and whether the agent may change it. Give it access only to the material needed, let it propose changes first, and check that the intended destination and owner are correct. A draft task is not the same as a created ticket; a requested update is not proof that the update succeeded.
Personal assistants with boundaries
Personal agents can gather trip options, compare products, prepare a meeting brief, or organize a reading list. Availability, prices, and terms can change, so ask for links and check the details before relying on a recommendation.
Authority can be staged. An agent might gather options, draft an itinerary, and then ask before booking. A recurring purchase can be scoped to a particular item, seller, maximum price, and frequency, with an approval step if those conditions change. Sending a message, spending money, changing an account, or deleting data requires a clearer boundary than collecting information. See the personal readiness guide for choosing a task and setting limits.
Computer use
Many systems have a website or form but no suitable integration. A computer-use agent can work through a visual interface using screenshots, clicks, and typing. Anthropic’s documentation describes this kind of tool and its use in a controlled computer environment.
The interface can change or display an unexpected popup; an agent can click the wrong control or misunderstand what happened. Use a limited account and a test environment where possible, check the resulting record, and provide a fallback when the agent gets stuck. Content on a page can also contain instructions that try to redirect the agent. Treat that content as data, restrict the agent’s access, and keep consequential actions behind enforced approval. The browser workflows and prompt injection guides explain these risks.
What agents should not do alone
An agent’s ability to draft or navigate a workflow does not establish that it should make the final decision. Set a human review or approval gate appropriate to the consequences, particularly for:
- Payments and purchases
- Legal commitments
- Medical advice and care decisions
- Employment decisions
- Security or access changes
- Deleting or exposing data
- Messages sent under a person’s name
Make the gate concrete: show the reviewer the proposed action, target, and relevant details before execution. Restrict the tool itself so an instruction to ask is not the only protection. If the action is rejected or the tool fails, report what actually happened. The approval scopes guide goes deeper.
Try one bounded task
Pick a recurring task with a result you can inspect and a limited cost of error. Give the agent the goal, relevant materials, allowed tools, and a stopping point. Ask it to return the artifact, its evidence, uncertainties, and any actions it actually completed. Then review a sample against your usual process, including the time spent checking and correcting it. If the result is hard to verify or exceptions are frequent, narrow the task or keep it with a person.
The better question is not simply whether an agent can perform a step. It is whether the complete workflow produces a useful result, and who catches a mistake before it matters. The delegation playbook provides a fuller template for assigning the work.