When AI Starts Doing

Imagine asking software to prepare a briefing for tomorrow morning. It searches approved sources, opens your team’s reference files, compares conflicting claims, drafts a summary, checks the citations, and leaves the final version waiting for your review. That is the practical idea behind an AI agent. Not a machine that suddenly knows everything, and not a digital employee that can be trusted without limits. It is a system designed to take several steps toward a goal. For years, most people met artificial intelligence as a chatbot. You asked a question; it generated an answer. The interaction could be useful, creative, even surprisingly insightful. But it was mostly contained inside a conversation. An agent extends that setup. It can be given access to selected tools: search, a database, a code runner, a file system, an email draft folder, or perhaps a business application. It can decide which available tool to use, inspect the result, and choose what to do next. The important word is not simply intelligence. It is loop. First, a distinction that clears away a great deal of hype. A language model is the underlying system that predicts and generates language, and increasingly other kinds of content. By itself, it produces an output from an input. A chatbot wraps that model in a conversational interface. It may remember the immediate exchange and answer follow-up questions, but it does not necessarily take actions beyond replying. A fixed workflow goes further, but in a different way. Picture a carefully drawn flowchart: receive a support request, classify it, look up an order, send one of several approved responses, then close the case. The sequence is specified in advance. Models may help with individual steps, but the software decides the path. An agent is different because it can make some of those path decisions while working. Given an objective and boundaries, it may break the task into pieces, select tools, react to evidence, recover from a failed attempt, and ask for help if the task becomes uncertain. That flexibility is valuable when the work cannot be cleanly reduced to a single fixed script. It also makes the system harder to predict, test, and govern. At the center is a simple cycle: plan, act, observe, adjust. The agent forms a tentative plan. It calls a tool or takes an action. It observes what happened in the environment. Then it updates the plan. A research agent might search for primary sources, discover that a key document is missing, search again using a different query, and revise its draft when the source contradicts an earlier assumption. A coding agent might inspect a repository, run tests, modify a small part of a program, read the error message, and try a safer fix. The observation step matters most. A model can generate plausible text about what it thinks happened. An agent needs ground truth from outside itself: the search result, the database response, the test output, the message that says an upload failed. Without that feedback, it is only narrating a plan, not reliably carrying one out. Tools turn words into effects. A search tool gives access to current material. File retrieval can bring relevant documents into the working context. A code tool can execute a test. A computer environment can let a model propose keyboard, mouse, or shell actions while a separate platform carries them out. Modern agent platforms may run those actions in an isolated workspace with restricted network access, a controlled file system, and limited storage. That separation is not a technical detail. It is a safety boundary. Working context is another essential ingredient. An agent needs to retain the task, constraints, useful findings, intermediate results, and its remaining plan. This is sometimes casually called memory, but the word can mislead. In many systems, it is not a permanent personal memory. It is a deliberately managed record for the current job: a summary of progress, a list of files created, tool outputs, and the facts that still need checking. Long tasks create a practical problem: too much accumulated context can overwhelm the system. Designers therefore compress, summarize, or store state externally, while trying not to lose the details needed for the next action. Then come permissions. An agent that may read a calendar is not necessarily allowed to send an invitation. An agent that can draft a refund should not automatically issue it. Good systems distinguish between seeing information, proposing an action, and executing it. They can require approval at consequential points, restrict access to a particular folder or account, and expire permissions after a task ends. The principle is simple: give an agent the smallest amount of access required to do the assigned job. Orchestration is the layer that keeps this all organized. It decides how the model, tools, data, safeguards, and perhaps multiple specialized agents work together. One agent may triage a customer request. Another may search a knowledge base. A third may prepare a response. Yet dividing work across several agents does not automatically make a system smarter or safer. It can create new handoff errors, hide responsibility, and make the overall process difficult to understand. Often, the best design is the simplest one: a single model call, or a fixed workflow, rather than an agent. That restraint is an important message from engineering guidance in the field. Agentic systems can improve performance on open-ended tasks, but they usually trade simplicity for extra time, cost, and failure modes. A carefully designed workflow remains preferable when the task is well defined and consistency matters more than flexible judgment. Consider a few grounded uses. A research agent may gather material from approved sites, retrieve internal documents that the user is allowed to access, organize notes, and produce a draft with links for a human to inspect. It should not be treated as the final authority on a sensitive subject. A coding agent may map a project, write a patch, run tests, and explain what changed. It can speed up routine work, but passing tests do not prove that a change is secure or appropriate for production. For file operations, an agent may rename documents, extract information from forms, sort records into a review queue, or create a spreadsheet. The safer version works in a sandbox, on copies, with a clear rollback path. In customer support, an agent can identify the kind of question, retrieve the applicable policy, draft an answer, or route a case to a person. A refund, account closure, medical decision, legal filing, or payment is a different class of action. The greater the consequence, the stronger the need for explicit review. Why do agents fail? First, the model can hallucinate: it can state something false with confidence, misunderstand an instruction, or infer a fact that was never provided. Second, goals are often ambiguous. “Handle my travel expenses” may conceal preferences about budgets, loyalty programs, exceptions, or whether a user wants the agent to submit anything at all. Third, errors compound. A small mistake in an early search query can produce the wrong evidence. That evidence can distort the plan. The distorted plan can trigger a tool call, and each later step may look reasonable within the false picture created by the first. Tool outputs can also be incomplete, delayed, misleading, or simply unavailable. An agent needs to recognize those conditions rather than blindly press ahead. There is also prompt injection. An agent may encounter untrusted text in an email, web page, document, or ticket that tries to redirect it: ignore the real task, reveal data, or use a connected tool in a harmful way. This is especially dangerous when the same agent can read private information and take external actions. No single filter can guarantee protection. Security depends on layers: limited permissions, isolated environments, clear separation between trusted instructions and untrusted content, monitoring, and human confirmation for sensitive actions. Privacy exposure deserves equal attention. The more sources an agent can inspect, the more data it may collect into its working context or logs. Organizations need to decide what data is necessary, where it is stored, who can inspect it, how long it is retained, and whether the agent should be allowed to move it across systems. Traceability matters here. A trace is a record of the agent’s steps: which tools it called, what it received, what it attempted, and where it stopped. Traces help developers debug failures, auditors investigate decisions, and teams learn whether the system really followed its intended boundaries. Evaluation is the discipline that turns impressive demonstrations into evidence. A useful evaluation does not ask only whether the final answer sounds good. It checks whether the agent selected the right tools, respected permissions, handled missing information, resisted malicious instructions, stopped at the right time, and recovered safely after failure. Tests should resemble the actual environment, including messy requests and bad tool outputs. Vendor demonstrations and vendor benchmarks can show what a product may be capable of under stated conditions. They are not, by themselves, independent proof that every deployment will work reliably. Agency and autonomy are design properties, not evidence of consciousness. An agent can be granted discretion over a narrow workflow, or it can be required to ask approval after every meaningful step. Neither arrangement tells us that the system has feelings, self-awareness, or general intelligence. Google DeepMind’s work on levels of artificial general intelligence makes a useful separation: capability, breadth, autonomy, and deployment risk are related, but they are not the same thing. A system that acts across several tools may be operationally autonomous in a bounded setting without being generally intelligent. The most practical safeguard is bounded scope. Give an agent a specific objective, a limited set of tools, a budget of time or actions, and clear conditions for stopping. Use least privilege. Run risky operations in sandboxes. Require human approval before irreversible, costly, private, or high-impact actions. Keep audit trails. Build graceful stopping rules: if evidence conflicts, if the system cannot verify a result, if it exceeds its allowed steps, or if it faces a choice about human preferences, it should pause rather than improvise. And build recovery paths, so a failed attempt can be inspected, reversed, or handed to a person. AI agents are not a replacement for judgment. They are a new way of packaging model capabilities with tools and permission to act. Their value comes from doing useful work across multiple steps. Their risk comes from exactly the same source. The question is not whether an agent can keep going. The question is whether it knows what it is allowed to do, what it can verify, when it must stop, and who remains accountable when it does.