What do you mean,
‘what do I mean’?

There's a moment in the movie Arrival where the world nearly ends over a translation.

Twelve alien ships have landed in different countries, and for a while nations are cooperating, sharing what they learn across a wall of video feeds. Louise Banks, the linguist called in to translate the alien messages, has finally decoded enough of the alien heptapod language to ask the question everyone wants to know: what is your purpose here?

The answer comes back as “offer weapon”.

Oh man, all the screens go dark, China starts getting aggressive, and all that international cooperation is right out the window.

Technically, the translation isn't wrong. The heptapod symbols really do mean something close to “weapon,” but also something close to “offer.” What went wrong was Louise's reading of the parts produced a bad reading of the whole. The heptapods had no concept matching the human category of weapon, and what they were really offering was closer to a tool, or a gift.

The word “weapon” landed inside a human frame built out of a ton of B-movie alien invasion anxiety.

Arrival is a great film, and it happens to be one of our leader Vijoy's favorites, which is how most of our org ended up watching it recently.

And it got me thinking about most of my agent design problems in a different way. Less of “did the agent do the right thing,” but more “what did the agent take this to mean, and did anyone get to look at that before it acted.” Everything we want out of working with these systems, delegating real work, building on each other's reasoning, accumulating something across a team rather than starting cold every time, depends on meaning surviving the trip between a person and a machine.

01The everyday version of “offer weapon”

You don't need an alien invasion, any ordinary workday will do.

Let's say, someone asks an agent to clean up the attack alerts for the network. The agent goes off and does exactly that, no problem, and comes back having consolidated forty noisy rules into six. Good work… Except what the person really meant was “stop paging me for things that turn out not to be attacks,” the agent read it as “reduce alert volume,” and three of the rules it merged away were the only ones watching for when someone slowly works through stolen passwords at a few tries a day, slow enough to look like people fumbling their own logins.

So nothing malfunctioned and every tool call succeeded, the agent completed the wrong task… correctly.

That sentence is the one I keep coming back to, because our whole vocabulary for agent safety is built around one kind of failure. We talk about permissions, approvals, guardrails, undo, human in the loop, and all of that governs what the agent may do. Almost none of our thinking governs what the agent understood the situation to mean.

You can have complete formal control over an agent's actions and almost no visibility into the interpretation that produced them. You approve the action, and what you actually approved was an agent's translation of your request.

02Two ideas, both portable

Hermeneutics, briefly, I promise.

Hermeneutics is the study of interpretation, meaning how understanding actually happens and what has to be true for it to happen at all. Its most useful insight is called the hermeneutic circle:

You understand the parts through the whole, and the whole through the parts.

The circle almost always gets demonstrated like this: Take the word “hand,” it could mean help, or applause, or a round of cards, depending on what surrounds it, so you need the sentence to read the word and the words to read the sentence. Got it? And yes, working out which “hand” I meant from the words nearby is literally what a transformer does, it's roughly what the whole architecture is for, and nothing shipping today gets that wrong.

Solved! End of article. You wish…

What hermeneutics is actually about is much bigger than a sentence, and we've all lived it. You join a team three weeks into a project. Someone says “we're not doing the Tuesday thing anymore” and you nod, because what else are you going to do? To really make any sense of that sentence you'd need to know what the Tuesday thing was, which means you'd need some picture of what this project has been through and who's tired of what. You don't have one, so you improvise. Then the next fragment arrives and you read it through that improvised picture, which sharpens the picture, which quietly changes what the first fragment meant. Nobody ever hands you the whole. You assemble it out of parts you're actively misreading, and the misreadings correct themselves on the way through. None of that is sitting in a transcript of the meetings.

Hans-Georg Gadamer added an insight in 1960, in a book called Truth and Method. Every statement is an answer to a question, and you haven't understood the statement until you've worked out which question it was answering. The question is the whole. The request is the part. And the question is almost never written down.

So: “clean up the attack alerts for the network” is an answer. The question behind it might have been how do I stop getting paged at 3am. It might have been how do I get this list presentable before the audit. It might have been how do I stop the team muting this channel entirely. Same eight words, three completely different jobs, and nothing in the sentence tells you which.

A transformer can tell you what those eight words mean. It can't tell you which question they answer, because the question was never in the sentence. It was in your week.

That's where questions live. In your week, in the last incident, in what your director said in a review, and sometimes nowhere at all, because the person asking hasn't formed it yet and would struggle to state it if you asked them straight out.

Gadamer had a second idea. Everyone who shows up to a conversation brings a horizon, meaning the whole field of assumptions, experience, and prior understanding they're interpreting from.

Arrival widens yours on purpose, which is the other reason I keep coming back to it. Its opening scenes read one way the first time through and a completely different way the second, once you know the thing below.

Heads up: The next sentence gives away the central turn of the film. It stays blurred until you decide to open it.

Nothing in those scenes changes on rewatching, only the context they're part of, because what looks like Louise remembering her dead daughter is her seeing a future she has not lived yetreveal spoiler. Watch it twice and the second viewing isn't a rewatch so much as a rereading, with every part meaning something it couldn't have meant the first time.

A model effortlessly resolves a word against its sentence. Resolving a request against a situation it can't see is a different problem entirely.

03What's already solved

Models got much better while nobody was designing for this.

Like I said, I can hear your brewing objection that most of this is all a model problem and the models are handling it. That's fair, and it's fair mostly because the models really are ahead of the interfaces.

Ask a current frontier model to lay out its reading of an ambiguous task before it starts and it will. Ask what it's assuming, which alternative reading it rejected, what falls outside the instruction, and you'll get credible answers. Every pattern I'm about to describe can be produced as text today, on request. I can also watch one think while it works, and several of the assistants I use keep memory across sessions. I use both of those every day and I'd rather not go back.

Forming the interpretation is model work, and it's improving fast enough that I am not betting against a lot of this being solved there. But deciding when to surface it, what persists, and how a correction propagates backward through earlier work is the system around the model, and it barely exists. Whether you get something you can edit one piece at a time, or a paragraph that scrolls by and is gone is the interface, and that's the part we keep skipping.

Long story, longer: better models make interpretations better, but they don't effectively make them visible, contestable, or durable. Those are properties of the system built around the model.

04The agent that has never met you

Everything so far assumes you're working with an agent that knows you a little.

That trace in the third tab of the graphic above is real, and it's from something I was doing last week. I'm working on an autonomous driving robot called Roger, and I told the agent I was working with that I was taking a break to run a 3D print, so I was powering Roger down. It went ahead and pushed my commit too, which I hadn't asked for and which was almost certainly the right call.

Read the highlighted line again, though. Absence of prohibition, it read it as permission, on the strength of a pattern inferred from a few hours of my behavior. Look, it worked out because the agent had watched me all session, and it knew my habits because it had been there while I formed them.

That's the easy case, and nearly all agent design today assumes: one person, one assistant, a relationship and memory that accumulates. But it's not the shape of the work that's coming.

If the Internet of Agents is right, and I think it is, most of the agents you deal with in a given week won't be yours. They'll belong to another team, another vendor, another company, and you'll meet one for a single task and never see it again. There'll be no session with you, no inferred preferences, possibly no memory of the last thing you objected to. What it has is a protocol handshake and whatever your request happens to say.

When an agent doesn't know you and won't remember you, showing you its working interpretation is the only channel left for the context a familiar assistant would have accumulated on its own.

05Connecting evolving interpretation

Human-agent hermeneutics.

So, the model reads the words fine, it can narrate what it decided, it can remember what you seemed to want, and none of that gives you a way to reach the reading before it becomes an action. When the agent knows you, that mostly works out. When it doesn't know you, and increasingly it won't, there is nothing between your request and its interpretation of your request.

That gap is what I've started calling human-agent hermeneutics, and naming it matters because you can't design for something you don't have a word for, and I love naming stuff.

The unit of design here is not the prompt, the response, or the action. It's the evolving interpretation connecting them.

Software has always assumed the human knows what they want, expresses it, and gets a predictable result, and agent interaction messes with all three. Intent is usually partial, with the agent filling the gaps from system instructions, conversation history, retrieved documents and a whole pile of assumptions, so what comes back isn't only an answer. It's evidence of what the agent took the situation to mean, which means you end up reading every output twice, once for content and once for what it reveals.

At the center is the exposure of a working interpretation: the agent's live representation of what's happening, what you intend, which constraints bind, and what should happen next. Not a transcript of its thinking, it can already show you that. I am talking about something you can take hold of and change.

06The loop

You can already watch most of this happen, but you still can't reach into it.

Express → Interpret → Expose → Realign → Act → Reinterpret

You and an agent enter a collaboration both with a horizon. Something partial gets expressed, the agent forms an interpretation, and then it says the consequential parts of that interpretation and you read it. From there you confirm, resist, or repair, it revises and acts, and those results can send you back to reinterpret the original request because the whole has changed.

Express, interpret, act, and reinterpret run in every agent product shipping today. Expose and realign are the two that need to become things you can act on, because they're the two that decide whether the other four go anywhere good. I also think that the interpretation usually doesn't sit in your head waiting to be retrieved either. Half the time it gets built between you and the assistant.

The difference from this example and a clarifying question is that nothing for the agent was uncertain. An agent only asks questions when it knows it doesn't know, and the mistakes usually happen when it's sure. So the reading gets surfaced either way, the reasoning isn't just passing text, there's an opportunity for a repair path, and the panel at the bottom attempts to tell you what any of it costs. It can't actually know that fully, but it can tell you what stops being true.

One design rule sits underneath it: make correction cheaper than repetition. Today, fixing one bad assumption means restating the entire request and hoping the good parts survive, which is a terrible deal and the reason people give up and hand-fix the output instead.

07Not every disagreement is a misunderstanding

An agent that caves every time isn't agreeing with you.

Now we get to the part where I respond to all of you out there screaming at me, “just have the agent ask clarifying questions!” When a human and an agent are misaligned, at least six different things could be going on, and they need completely different responses:

A system that treats all six as “So sorry, I misunderstood you” becomes the sycophantic thing we hate about agents, abandoning its answer every time you push back, including when you're the one who's wrong and including when its evidence was better than yours. On the flip side, a system that treats all six as “No, you don't understand me!” becomes a real pain in the neck.

Almost every agent I use is firmly in the first category, even with a lot of system-prompt tuning. Push back on anything and you eventually get “You're absolutely right, let me fix that.” Here's the part that matters given everything in the last section: with a reasoning trace open, you can watch it happen. You can read the model registering that you disagree, deciding to reconsider, and reversing itself, with no new evidence anywhere in the exchange. Seeing it does not stop it.

Research says the same thing with numbers. Shaikh and colleagues found models roughly three times less likely than people to ask a clarifying question and sixteen times less likely to follow up, while over-producing acknowledgments that give, in their words, a false sense of understanding. Sharma and colleagues showed leading assistants abandoning correct answers when a user simply asks whether they're sure. The shift tracks the social framing, not the strength of the evidence.

So here are two things I'd defend here:

Agreement is not evidence of understanding. Compliance is not evidence of realignment.

08Running it the other way

Permission is not comprehension.

Everything so far is about you inspecting the agent, so turn it around, because the agent has the same problem about you.

“Yes, go ahead and merge the accounts.”

Permission granted, clear and unambiguous and authorized, and the person may not know that merging will collapse two permission sets into one, combine billing history, and be effectively irreversible.

Now, credit where it's due, a good agent often catches this all on its own and you've watched it happen. You say push and commit, and it comes back with “if I do that the branch protection rule rejects it, do you want a PR instead.” That behavior is real, it's common, I get it.

But it isn't reliable, because whether you get the warning is a judgment the model makes fresh every time, so the same action gets flagged on Tuesday and sails through on Thursday. Is that a guardrail or just a roll of the dice? And it isn't a test. The agent says the consequential thing, you say yes, and nothing anywhere distinguishes a yes that read the warning from a yes that scrolled straight past it.

That's the real gap in this direction. Not that an agent can't tell you what you're about to do, but that it has no way to find out whether the telling landed, and no way to keep the answer once it does. You said you meant a permanent merge, and next week the same conversation starts from nothing.

I love a good principle, so here's one I'd use for this: reciprocal fallibility, asymmetrical authority. Both parties can be wrong, in different directions, and most chat interfaces collapse all of it into a neatly generated text paragraph.

09Why this matters for what we're building

From the Internet of Agents to the Internet of Cognition.

At Outshift we've spent a long stretch on the Internet of Agents, the connective tissue that lets agents from different vendors discover each other, prove identity, exchange messages, and be observed.

Vijoy has been pushing the org toward a next move, the Internet of Cognition. His framing is that connection isn't the hard part anymore, since agents already collaborate on tasks, but what they can't do is think together. He calls the failure mode semantic isolation: the pipes are fine, but the meaning doesn't survive the trip.

Its architecture answer is cognition-state protocols, a shared cognition fabric that holds institutional memory across interactions, and cognition engines that amplify and constrain. Underneath sit three requirements: shared intent, shared context, and collective innovation.

Read those three as a design brief instead of an infrastructure one. Shared intent, shared context, and building on each other's reasoning are not (only) engineering problems, they're interpretation problems. Cognition-state protocols are, in Vijoy's own word, a grammar for agents to align on meaning, and that's the machine-facing half.

Human-agent hermeneutics is the other half. If the fabric is going to carry meaning between agents, something has to carry meaning across the boundary where the human sits. A cognition fabric that agents can read and humans can't inspect is just a faster way to propagate a bunch of misreadings.

10What to actually do

What to start changing for the enterprise.

1. Treat every interpretation as provisional. Don't render inferred intent as settled fact, and let a finished result argue with the premise that produced it.
2. Expose interpretations before consequential action, and make correcting one assumption cheaper than restating the whole request.
3. Separate what was observed from what was inferred. Users should be able to tell the difference at a glance.
4. Show what changed, and preserve what didn't. A meaning diff beats “Got it,” and acting together doesn't require pretending you agree.
5. Make memory contestable. Anything persistent about a person, a project, or an org has to be inspectable, scoped, and correctable.
6. Test understanding by use, not by paraphrase. Fluent acknowledgment is not evidence that anything changed.

I think the more knowledge work that gets delegated, the less we'll see agents as the bottleneck. Our focus needs to shift to whether the people accountable for the work can see, and change, what those systems took the work to mean.