After sixteen years, HTTP finally has a new method.
QUERY solves a problem every backend engineer has encountered. Complex searches have spent years pretending to be POST requests simply because GET could not carry structured request bodies. The new method gives us something we’ve wanted for a long time: rich queries with the semantics of a safe, idempotent read. It is a thoughtful improvement to HTTP, and one that will almost certainly find its place over the next few years. (RFC Editor)
Reading the RFC, however, we couldn’t help thinking about how much the world has already changed. Because AI agents have quietly moved the hardest query somewhere else.
The first query no longer goes to your server
Imagine asking an agent: “Find the best suppliers for this component.”
The first query is not sent to your API. It is sent inward. Before the agent reaches a database, before it calls a search endpoint, before it invokes an MCP server or executes a QUERY request, it has already begun answering a different question.
What does the user actually want? That internal query is vastly more consequential than the HTTP request that eventually follows.
The agent decides what information is relevant. It decides which systems deserve attention, which tools should be invoked, and which paths are worth exploring. By the time an HTTP request reaches your infrastructure, the most important query has already been executed. It simply wasn’t executed against your backend. It was executed against intent.
The query keeps changing
The elegance of the new HTTP method is that it treats a query as something stable. A client constructs a request, sends it, and expects the server to process it safely and repeatedly. Agents don’t work that way. An agent rarely executes one query. It continuously rewrites its own queries.
A search leads to another search. New information changes the hypothesis. The retrieval strategy evolves. Memory changes what appears relevant. A different tool becomes available. The workflow reorganizes itself.
The query is no longer a request. It becomes a living object that evolves while the task is still running. That evolution is precisely what makes agents powerful. It is also what makes them difficult to control.
The problem isn’t the HTTP request
One of the consequences of this shift is that traditional observability begins too late. By the time a QUERY request reaches your server, the interesting decisions have already happened.
Why this endpoint? Why this dataset? Why this document? Why this tool? Why now?
Those decisions never appear in your HTTP logs because they were made before the first network packet left the machine.
Traditional APIs answer: “What was requested?” Agentic systems force us to answer a different question: “Why did this become the request?”
That is a fundamentally different control problem.
Intent becomes the invariant
This is one of the ideas that shaped ArmorIQ from the beginning. We have no interest in preventing agents from adapting. Prompts should evolve. Plans should evolve. Retrieval strategies should evolve. Even runtimes should evolve if they become more effective.
Trying to freeze those things would remove much of what makes agents valuable. The one thing that should not quietly evolve is the user’s intent. Everything else may change. The purpose that justified the task should remain the invariant around which those changes occur.
That is why our architecture begins with intent rather than execution. The HTTP QUERY method recognizes that queries deserve to become first-class citizens of distributed systems. We believe AI agents are already forcing the next step.
Before we govern HTTP queries, we will need to govern the much more important query that every autonomous system asks itself:
“What do I think the user actually wants?”
That is the first query every agent executes. It is also the one that determines everything that follows.
