Agents Are Not Magic

How AI Models Actually “Use Tools” — and Why the Answer Should Make You Feel Better, Not Worse

You have probably seen the demo by now. Someone stands on a stage, or shares their screen on a webinar, and types a sentence into a chat box: “Book me a flight to Seattle next Thursday and put it on my calendar.” A few seconds pass. Then, as if by sorcery, a flight appears. A calendar invite shows up. The room makes the sound a room makes when it has just watched a machine do something that used to require a human being.

I want to take that feeling apart, gently, because it is built on a misunderstanding — and the misunderstanding is expensive. It is the reason executives come to believe you can buy “an agent” the way you buy a stapler, plug it into the business, and watch the work get done. It is the reason people either wildly overtrust these systems or dismiss them as pure hype. Both reactions come from the same place: nobody ever told them what is actually happening under the hood.

So let me tell you. By the end of this, you will understand how an AI model “uses a tool” better than most of the people currently trying to sell you one. You will never watch an agent demo the same way again. And, fair warning, you may come away wanting one built properly for your own business — which is a conversation I am always happy to have.

Let me start with the part nobody puts on the slide.

The uncomfortable truth: the model cannot do anything

Here is the fact at the center of every AI agent, the one the marketing carefully steps around: the model itself cannot do a single thing in the real world. It cannot send an email. It cannot look up today’s stock price. It cannot query your database, click a button, move a file, or book that flight. It has no hands. It has no internet connection. It has no ability whatsoever to act.

What a large language model actually does — the entire whole of what it does — is predict the next word. You give it some text, and it produces the most plausible continuation, one small piece at a time. Microsoft’s own developer documentation for its agent tooling states the limitation about as bluntly as a corporation ever states anything: a language model generates text, and on its own it cannot send an email, query a database, or reach out to any outside service. That capability simply is not in the box.

That is the machine. It is a staggeringly good text-prediction engine, trained on a large fraction of everything humanity has ever written, and it is genuinely extraordinary at that one job. But it is a writer, not a doer. When it tells you “I’ve booked your flight,” it has not booked anything. It has produced the sentence a helpful assistant would produce. Left entirely to itself, a model that claims it sent your email is exactly as truthful as a novelist who writes “and then she sent the email.” Words on a page, and nothing more.

So if the model can only write, how on earth does an “agent” send real emails and book real flights? That is the trick — and it is both simpler and more clever than the marketing lets on.

The trick: a “tool call” is just a special piece of text

Here is the sleight of hand. Because the model can only produce text, we taught it to produce one very specific, very structured kind of text: a little written request that says, in effect, “I would like to use the weather tool, and the city I care about is Seattle.”

In practice, that request looks something like this — written in a tidy format called JSON that computers find easy to read:

{ “tool”: “get_weather”, “arguments”: { “location”: “Seattle” } }

That is the entire mechanism. When the model decides it needs outside help — real-time information, or an action in the world — it does not magically reach out and grab it. It writes a note. And to the model, writing that note is no different from writing any other sentence. It is still just predicting the next chunk of text. It was simply trained, during its education, on thousands of examples showing when such a note is appropriate, which tool to name, and what details to put inside it. So it learned the judgment: when to ask for a tool, which tool to ask for, and with what specifics — all expressed as text, because text is the only thing it can ever produce.

I want to underline how important this is, because it is the single fact that dissolves the entire mystique. The model never runs anything. It only ever asks. It writes “I’d like to call the weather tool for Seattle,” and then it stops and waits — the way you might scribble a request on a sticky note and leave it on a colleague’s desk. Whether anything actually happens next is completely out of the model’s hands.

Which raises the obvious question: whose hands is it in?

The handoff: where the real work lives (and why it’s a safety boundary)

This is where the actual work happens, and where the actual engineering lives — the part that never makes it into the demo.

Sitting all around the model is ordinary software. Code that a human being wrote. When the model produces its little written request — “call the weather tool for Seattle” — that surrounding code is what reads the note, recognizes it as a request to use a tool, and then goes and does the real thing. It calls the genuine weather service. It runs the actual database query. It hits the real flight-booking system. It gets back a real answer — “cloudy, high of fifteen degrees” — and then it hands that answer back to the model as a fresh piece of text: here is what the weather tool returned. Only now, holding that real information, can the model write its reply to you.

Read that sequence again, because there is something quietly profound buried in it. The model asks. Your code decides whether to obey. The model is not in charge. It cannot reach past the edge of its own text box. Everything it wants done has to pass through software that a person designed — and that software can inspect the request, refuse it, clean it up, log it, or demand that a human sign off before anything at all happens.

Microsoft’s documentation calls this separation “a key safety boundary,” and the phrase is worth sitting with. The reason a well-built agent can be trusted to touch your systems at all is precisely that the model does not have its finger on the button. It writes a request; a gatekeeper you control decides what to do with it. So when you hear someone worry that an AI might “go rogue” and start deleting things, the honest answer is that a model, by itself, cannot delete anything. It can only ask. Someone had to build a door and hand it a key. Whether that door has a lock is an engineering decision — your engineering decision. Hold onto that, because it is the entire argument for doing this properly.

So far we have one request and one answer. That is not yet an agent. An agent is what you get when you put that exchange into a loop.

The loop: how a text predictor starts to look like it’s “doing things”

Watch what happens when you run that little ask-and-answer exchange over and over, automatically.

You ask a question. The surrounding software packages up your question along with a menu of the tools that happen to be available — each one described by a name and a short explanation of what it does — and sends the whole bundle to the model. The model reads it and produces one of two things: either a normal answer, or one of those written tool requests. If it is a normal answer, you are done; that is the reply. But if it is a tool request, the software springs into action. It runs the requested tool, gets the result, adds that result to the running conversation, and sends the whole thing back to the model again. Now the model looks at everything it knows so far — your original question, plus the fresh information the tool just returned — and decides what to do next. Maybe it now has enough to answer. Maybe it needs another tool. If so, the cycle simply repeats.

That cycle — the model asks, the software acts, the result goes back, the model looks again — is the beating heart of every AI agent that has ever impressed you. Run it once and you get a weather lookup. Run it a dozen times and the model can search a flight database, compare the options that search returned, pick one, and then place a booking, each step feeding the next. The model appears to be reasoning its way through a task and getting real work done. What is really happening is that a very good writer is being handed a fresh sheet of paper after every step, with the latest facts written on it, and asked the same question again: given everything you now know, what next? The intelligence you are watching is real. But the “doing” is happening in the plumbing around it.

And here is the thing about that plumbing: someone has to build it. Someone has to write the loop, define the tools, run them safely, and feed the results back in exactly the right order. For years, every team building a serious agent had to construct this scaffolding themselves, from scratch, over and over. Which brings us to the tool this article is really about.

Microsoft Agent Framework: someone finally wrote the loop for you

In April of 2026, Microsoft shipped the 1.0 release of something called the Microsoft Agent Framework. A moment of context is worth it here, because this is not a science project. It is the merger and successor of Microsoft’s two previous agent toolkits — Semantic Kernel, which came out of the Azure side and was built for enterprise plumbing, and AutoGen, which came out of Microsoft Research and was built for getting multiple AI agents to talk to one another. The same teams that built those two combined them into a single, open-source, production-grade framework that runs in both .NET and Python. If your business runs on the Microsoft stack — and an enormous number of businesses do — this is now the officially blessed way to build agents.

What the framework does, at its core, is write that loop for you. You no longer have to hand-code the ask-and-answer cycle — the part that detects a tool request, runs the tool, and feeds the result back. You simply hand the framework your tools, the specific things you want your agent to be able to do, such as “look up a customer’s order” or “check inventory for this product,” and the framework orchestrates the rest. It notices when the model wants a tool, runs it, returns the answer, and keeps the conversation coherent, all automatically. As a working .NET architect, I will tell you plainly that this removes a genuinely large amount of tedious, error-prone work, and it does it well.

But — and this is the pivot the whole piece has been building toward — writing the loop is the easy part. A loop is not a system. The gap between “the model can call a tool” and “I can trust this thing to run for twenty minutes against my real business without setting fire to something” is enormous. And it has a name.

The harness: the scaffolding that turns a writer into an operator

The industry’s word for the full scaffolding wrapped around a model — everything that turns a text predictor into something that can actually get a job done — is the harness.

Microsoft defines it about as clearly as anyone: a harness is the scaffolding you build around a language model to turn it from a thing that writes into a thing that does. By itself, the model is a writer and nothing more. To get it to call tools, grind through a task with many steps, keep track of what it has already done, and stay at it until the work is genuinely finished, you need a piece of software running around the model that drives the entire process. That driver is the harness. The coding assistants you have heard about, the autonomous agents that run for an hour and hand back a finished piece of work — every single one of them is built on some form of harness. It is the engine wrapped around the model.

Think of the model as an extraordinarily talented worker with two profound disabilities: it has no memory, and it cannot touch anything. Every time you speak to it, it has forgotten everything that came before. And it has no hands. The harness is everything you have to build around such a worker to get useful work out of them — the notebook you keep on their behalf, the to-do list you maintain for them, the assistant who actually runs the errands they request, the supervisor who double-checks the risky ones, and the manager who keeps them pointed at the goal until the job is actually done. Let me walk you through what that really involves, because this is the part that separates a demo from something you would stake your business on. And nearly every item on this list is a place where a slick demo quietly cheats.

What a real harness has to handle

Start with memory, because it is the most counterintuitive. The model remembers nothing between steps. It is amnesiac by design; each time the surrounding software sends it the conversation, it is reading the whole thing fresh, as if for the very first time. So something has to hold the thread of the conversation and re-present it at every single step. That “something” is part of the harness. Without it, your agent forgets what you asked three sentences ago.

Then there is the size limit, which is subtler and nastier. A model can only read so much text at once — its “context window,” a fixed budget for how much it can hold in view at one time. On a short task this never matters. But on a long job — an agent that calls thirty tools while researching something — the running conversation keeps growing, every tool result piling on top of the last, until it threatens to overflow that budget. When it overflows, the whole thing breaks. So a serious harness has to watch the conversation’s size and intelligently trim and summarize the older parts to keep it under the limit without losing the plot. Microsoft calls this “compaction,” and the fact that it is a named, built-in feature should tell you it is a real problem that real systems hit. The demo never runs long enough to hit it. Your production workload will.

Multi-step work needs a plan the model can hold onto. When a task has fifteen steps, you cannot simply trust a forgetful worker to keep the whole plan in their head, because they do not have a head to keep it in. So the harness maintains a persistent to-do list that the agent writes at the start and consults as it goes, checking items off as they are completed. And a good harness can run the work in two distinct gears. There is a planning gear, where the agent is interactive: it asks you clarifying questions, drafts its plan, and waits for your approval before doing anything consequential. And there is an execution gear, where, plan approved, it goes off and does the work on its own, reporting back as it goes. That plan-then-execute rhythm is exactly how you would want a competent human contractor to operate, and it does not happen by accident. The harness has to provide it.

Now the part that should matter most to anyone putting this anywhere near a real business: approval. Some actions are perfectly fine to let an agent take freely — reading data, running a search. Others are emphatically not — spending money, deleting records, sending an email to a customer under your company’s name. A real harness lets you draw that line. You mark the dangerous tools as requiring human approval, and when the agent wants to use one, it stops, surfaces the request to a person, and waits for a yes or a no before it proceeds. This is the “human-in-the-loop” pattern, and it is not optional decoration. It is the difference between a system you can responsibly deploy and a lawsuit waiting to happen. The demo, of course, approves everything automatically, because pausing for a human would ruin the magic. Your real system had better not.

There is the deeply unglamorous matter of not losing your work. When an agent is forty steps into a sixty-step job and something crashes — a network hiccup, a server restart — you do not want it starting over from the beginning. So a mature harness saves its progress continuously, after every single step, so it can pick up exactly where it left off. And there is the matter of being able to see what the thing actually did. When an agent makes a decision you did not expect, you need a detailed record — every tool it called, every argument it passed, every result it got back — so you can understand its behavior and, if necessary, correct it. This is “observability,” and building agents without it is like flying a plane with the instrument panel painted on. It is a subject I care enough about to have built my own framework around it; here I will simply say that any harness worth using has it baked in.

That is the harness. That is the real work. Not the loop — the loop is a weekend. The harness is memory, and size management, and planning, and approval gates, and crash recovery, and observability, and a dozen more decisions about what your specific agent is allowed to do and how much rope to give it. This is the iceberg beneath the demo’s waterline.

Agent Framework hands you the harness — but not the business

Here is the good news, and it is genuinely good. You do not have to build that harness from scratch either. One of the more significant things Microsoft added to Agent Framework — announced at their Build conference in June of 2026 — is a ready-made, batteries-included harness. In plain terms, they took every one of the hard capabilities I just described — the memory management, the size compaction, the to-do list, the plan-and-execute gears, the approval gates, the crash recovery, the observability, even a built-in web search — and packaged them into a single pre-assembled chassis you can pick up and use. Every feature is switched on by default, and each one can be individually turned off or customized if your situation calls for it. For a .NET shop, standing up a genuinely capable agent is now a dramatically shorter road than it was even a year ago.

But notice what the framework does not, and cannot, do for you. It hands you a superb, professionally built chassis. It does not know your business. It does not know which tools your agent needs — because those tools are your operations: your order system, your inventory, your customer records, your particular way of doing things, all of which have to be built and connected by someone who understands both the technology and what you actually do. It does not know where your dangerous lines are, which actions may spend money freely and which must never happen without a human saying yes. It does not know how much autonomy is appropriate for your risk tolerance, your compliance obligations, your customers. All of that is judgment and craft. And it is exactly the work that stands between “we installed the framework” and “we have an agent our customers can trust.”

This is the sentence I most want you to leave with: you cannot buy an agent the way you buy a stapler. You can buy an outstanding chassis. Someone still has to build the car around it — for your road, with the brakes in the right places. That someone is the whole point, and I will come back to it.

Why “not magic” is the best news you’ll hear all quarter

Let me close the loop on the title, because the reframe matters more than any single fact in this piece.

When people believe agents are magic, they make two equal and opposite mistakes. Some fall in love and hand the thing the keys to everything, trusting a system they do not understand simply because it seemed to work in the demo. Others sneer and write the whole field off as a bubble, missing genuinely transformative tools because they cannot see past the hype. Both camps are reacting to the same illusion: the idea that there is some inscrutable intelligence in the box, doing things by means no one can quite explain.

But you now know that there is no magic in the box. There is a phenomenal text predictor that can only write, wrapped in ordinary, inspectable, controllable software that does the actual doing. And that is the best possible news, because magic cannot be debugged, audited, secured, or trusted — but engineering can. The very fact that an agent is plumbing all the way down is precisely what makes it possible to build one reliable enough to put in front of a paying customer. You can put a lock on the door. You can watch every move. You can require a human signature on anything that matters. You can test it, measure it, and improve it. None of that is possible with a miracle. All of it is possible with a machine.

Which is why the companies actually winning with this technology are not, for the most part, the ones with access to the smartest model — everyone has access to roughly the same models. They are the ones who built the best harness around the model: the tightest tools, the most sensible guardrails, the right amount of autonomy for the job, and the observability to know what happened and fix it when it drifts. The model is the commodity. The scaffolding is the craft. The hype sells you the model. The results come from the harness.

So the next time you watch that demo — the sentence typed into a box, the flight appearing as if by sorcery — you will know exactly what is happening. A brilliant writer is producing a written request. Some carefully built software is reading it, deciding whether to obey, doing the real work, and handing the answer back. And the entire question of whether that system is a toy or an asset comes down to how well that surrounding software — that harness — was built. That is not magic. That is the job. And it happens to be my job.

If you want one built right

If you have read this far, you understand agents better than a distressing number of the people currently selling them. And if some part of you is now thinking, “I want one of these wired into my actual business — connected to my real systems, with real guardrails, built by someone who knows exactly where the demos cheat” — then we should talk. That is precisely the work I do: production agents on the .NET stack, with the harness built for your operations, your risk tolerance, and your road. Not a magic trick. A system that ships.

About the Author

Gal Ratner is the founder and CTO of Inverted Software and WhiteStar Labs, and Chief Architect at Prana Entertainment, a Las Vegas–based enterprise software and AI consultancy. Across nearly three decades on the Microsoft and .NET stack, he has shipped production systems for clients including Microsoft, Sony, Rockstar Games, 2K Games, Best Buy, and Allegiant Air, and was employee number six at Break.com. His current work sits squarely in agentic AI in production — Microsoft Agent Framework, MCP servers, retrieval pipelines, SQL Server 2025 vector search, and his own PLogger observability framework — building the kind of harness this article describes for companies that need agents to do more than impress a room. He writes about what actually ships, and what only pretends to. When he is not architecting AI systems, he trains Brazilian jiu-jitsu, rides motorcycles, and co-hosts Edge Grip Podcast. He is known, not by accident, as “the .NET AI guy that ships.” Reach out if you would like something built.

Edit 9/12/2026: I wrote a much needed part two here: