When AI Starts Acting

When I first started using artificial intelligence, my relationship with the machine was simple. I asked a question, and it gave me an answer. Sometimes the answer was useful, sometimes it needed correction, but the exchange stayed inside the conversation. I could read what the machine said and decide what to do with it. At that stage, I thought the most important question was whether the answer was correct.

Then I began noticing something different. AI was no longer limited to telling me how a job could be done. In some systems, it could search for information, inspect files, operate software, call tools, and carry out steps toward a result. I was looking at a machine that could move beyond conversation and interact with the world outside the chat. That was when I realized an AI that answers and an AI that acts are not the same thing.

The word I kept encountering was agent. I came to understand an agent as software that could work toward a goal on behalf of a person or organization, using information from its environment and whatever capabilities it had been given. Agentic AI took that idea further by allowing a system to work through multiple steps rather than producing one response and stopping. I could give the system an objective, and it might decide that several smaller operations were needed to reach it. But giving software a goal did not mean I had given it unlimited authority.

I learned that tools were what made many of those actions possible. A language model might explain how to inspect a file, but access to a file tool could allow a connected system to inspect it. Search tools could retrieve information, code tools could execute programs, and APIs could connect one application to another. Tool calling was the process through which the model selected and requested an available operation. The difference mattered because a sentence on the screen could now lead to something happening beyond the screen.

Once the system could use several tools, I began hearing more about workflows. A workflow was simply a connected sequence of steps, but I quickly understood why the order mattered. One operation might collect information, another might examine the result, and another might prepare the next action. Orchestration was the coordination that kept those pieces working together. I had to think about which step depended on another and what should happen when a step failed or produced an unexpected result.

I also discovered that one agent did not have to perform every part of a complicated job. A larger task could be divided among specialized sub-agents, with one examining information while another prepared a different part of the work. When responsibility moved between them, that transfer was called a handoff. Several cooperating agents could form a multi-agent system, and people sometimes used the word swarm for groups working together or in parallel. I learned not to confuse the impressive language with proof that the coordination was reliable. Every handoff still needed enough context for the next participant to understand the job.

The more I learned about these systems, the more I questioned autonomy. How far should software be allowed to proceed without returning to the person who gave the instruction? A system might be allowed to research, organize information, or prepare a draft without asking permission at every step. That did not mean it should automatically publish the draft, delete records, send money, or change a live application. Autonomy was a matter of degree, not a switch that turned all human responsibility off.

That was where human oversight became part of my understanding of intelligence. I learned the expression human in the loop, which described a person reviewing, approving, correcting, or taking control at important points. I also learned about guardrails, the checks and boundaries intended to stop, reject, verify, or escalate certain actions. A sandbox offered another kind of protection by allowing software to operate inside a more limited environment. None of these controls made mistakes impossible, but they gave me ways to separate useful capability from unnecessary exposure.

I started asking questions that sounded simple but carried serious consequences. Could the agent read a particular file? Could it change that file, send a message, execute a command, or publish something for other people to see? Did the person who requested the job actually have permission to authorize those operations? I understood that a system could know exactly how to perform an action without having the right to perform it. Knowing how and being allowed to do it were two different things.

The distinction became clearer when I learned about authentication and authorization. Authentication concerned verifying who a user or system was. Authorization concerned what that identity was allowed to access or do. Permissions described the particular capabilities that had been granted. I could recognize a person, a service, or an agent without automatically opening every door to them. Identity was not the same as permission, and permission was not something an AI could create merely because it had found a way to complete the task.

As I continued building, I encountered another term: MCP, the Model Context Protocol. I understood it as a standardized way for compatible AI applications to communicate with external tools and information sources. That could make connections easier to organize instead of inventing a completely different interface for every service. But a common connection method did not settle the questions of trust, access, or responsibility. The tools still needed appropriate boundaries, and the results still needed verification.

Some of the language surrounding AI sounded even more dramatic. Recursive self-improvement was one example. The idea described a system contributing to improvements in its own capabilities or development process, potentially allowing later rounds of improvement. I had to separate that concept from the ordinary ability to call tools, delegate work, or run a longer workflow. An agent that could complete tasks or coordinate other agents was not automatically capable of redesigning and improving its underlying model. The distinction helped me keep my understanding grounded in what a system could actually demonstrate.

By this point, I was no longer thinking about artificial intelligence as a machine that simply answered questions. I was thinking about an entire operating arrangement: models, tools, identities, permissions, workflows, people, and the records needed to understand what happened. A useful answer was one thing, but a completed action introduced a different level of responsibility. If an agent changed a file, I wanted to know what changed. If it used a tool, I wanted to know which operation had been performed and whether that operation had been authorized.

This connected directly to what I had already been learning while building MatrixAligner. A request was not authorization, authentication was not authorization, and the existence of a route did not grant execution authority. I could not treat a working button, an available tool, or a successful technical response as proof that an action should have happened. Those distinctions were not obstacles placed in the way of building. They were part of understanding what I was building and how to remain responsible for it.

I also began to understand why evidence mattered after an action was complete. A system could report success, but I still needed to know what the report was based on. Had the intended file actually changed? Had the message really been sent? Was the result visible where it was supposed to appear? An agent's explanation was not a substitute for checking the outcome. The more independent the system became, the more important it was to preserve a way for people to examine and correct its work.

I do not see this chapter as a warning against AI agents. I see it as part of learning how to use them responsibly. Tools, workflows, and specialized agents can help people accomplish work that would otherwise take much longer. But speed and capability do not erase the need for human decisions, especially when the consequences extend beyond a conversation. The lesson I carry forward is that the ability to act does not create the right to act.

That is what I want readers of The Living Book to understand as we move toward more capable AI systems. Learning the language of agents is useful, but understanding the responsibility behind that language is even more important. I want people to recognize the difference between a machine preparing an action and a machine carrying it out, between an identity and its permissions, and between a convincing report and verified evidence. The moment AI could act, intelligence was no longer the only question. Authority became a question too.