Tools for Delegated Thought

Five rows. Nothing crazy. You’re just asking a computer to show you the beginning of a DataFrame.

But let’s pretend we’re on a Magic School Bus ride and explore exactly what is happening when you look at the result of df.head().

Maybe a column has unexpected values. The dates look wrong. You check the types, run another cell, and discover the numbers are strings. You fix it, try a groupby, and the result looks off. Maybe you lost a column. Maybe the join duplicated half your observations. You go back, change something, and run it again. Eventually you find what you were looking for, or you discover that your original question wasn’t very interesting. You dig until you know you can defend your conclusions with the data and your knowledge, then you put the shovel down.

Notebooks aren’t magical learning machines. I’ve run plenty without understanding everything inside them, and anyone who’s copied code from Stack Overflow knows that manual execution doesn’t guarantee comprehension. But there was something about the interaction that mattered: you had to keep touching the work. Not in an abstract way, not in an optional way. Not in a please explain what that means, my dear ai agent way. You actually had to be in the notebook running cells.

Even when you were running a copy of somebody else’s notebook, you still had to inspect intermediate results, fix mistakes, rename variables, or adapt something to your environment. The work kept giving you opportunities to notice what you didn’t understand.

Now I can ask an agent to explore the dataset. It can inspect the schema, form hypotheses, write and execute code, encounter errors, repair them, try another method, and return with a polished explanation. I can even ask the agent to create a dataset from scratch exactly for my purposes. I can challenge its assumptions, ask follow-up questions, or suggest a different direction. Sometimes the conversation is genuinely illuminating. The agent proposes an investigation I wouldn’t have considered, and we end up somewhere neither my original question nor my existing knowledge would have taken me.

I have no desire to relinquish this power. When I think about my experience with GPT-2 to understand how the Titanic dataset works, this looks like magic in comparison.

But I’m no longer present for every intellectual step, and I may never see the intermediate states. I don’t see the failed join, wrestle with the distribution that makes no sense, or encounter the assumption that turned out to be false. The agent handles those things and delivers the conclusion. Worse, when I don’t understand what my agent is doing, I amplify the subtle hallucinations until someone who knows better corrects me. If my agent is feeling kind enough, they might even let me know along the way that they found something that is a little bit bizarre.

By hand8 steps you see

1. In [1]df.head()A column has unexpected values.
2. In [2]df["date"].head()The dates look wrong.
3. In [3]df.dtypesYou check the types: the numbers are strings.
4. In [4]df["amount"] = df["amount"].astype(float)You fix it.
5. In [5]df.groupby("region").sum()You try a groupby, and the result looks off.
6. In [6]df.columnsMaybe you lost a column.
7. In [7]df.merge(orders, on="id")Maybe the join duplicated half your observations.
8. In [8]# change something, run it againEventually you find what you were looking for.

Delegated8 steps, folded away

> explore this dataset and explain what you find

✓ Ran 8 steps Show

1. df.head()Loaded 12,480 rows, 9 columns.
2. df["date"].head()Dates are stored as text. Parsing them.
3. df.dtypesamount is a string. Converting.
4. pd.to_numeric(df["amount"], errors="coerce").dropna()212 values wouldn’t parse. Dropped them.
5. df.groupby("region").sum()Totals look high. Checking the join.
6. df.columnsAll columns present.
7. df.merge(orders, on="id").drop_duplicates("id")The join duplicated 3,104 rows. Kept the first of each.
8. df.groupby("region").sum()Recomputed. Writing it up.

“West drives 38% of revenue, and growth has been steady since March. The data needed some light cleaning first.”

The same eight steps happened. Two were judgment calls: 212 rows dropped and a join deduplicated. The answer calls that “light cleaning.” Open the steps to see them.

I used to encounter ignorance in the course of getting things done. Now I have to go looking for it.

Those encounters weren’t always wasted effort. Some of them were how I learned. The interface has made the work more opaque, and with it many of the places where I might have encountered my own ignorance. I used to encounter ignorance in the course of getting things done. Now I have to go looking for it.

This doesn’t mean my new capabilities are somehow illegitimate. If I can accomplish something with an agent that I couldn’t accomplish without it, that’s a genuine expansion of what I can do. But consider three statements:

They sound similar, but they make different claims. The first might be true because I have access to a capable system. The second depends on what we mean by I. The third is a claim about knowledge I may not possess.

I’ve caught myself sliding between them without noticing. And I suspect this will become a more important distinction as the systems improve.

In July 1945, Vannevar Bush published As We May Think in The Atlantic. He had spent World War II overseeing American scientific research, and he was concerned about a problem anyone who’s opened a browser since 2019 will recognize: we have become remarkably good at producing information but not so good at making use of it.

Bush imagined a machine called the Memex. Picture a desk with screens, controls, and an enormous personal library stored on microfilm. You could retrieve documents, annotate them, and create connections between pieces of information. Bush called these connections associative trails. Instead of navigating knowledge solely through rigid indexes, you could follow relationships between ideas, return to a trail later, extend it, or share it with somebody else.

The nerd in me finds the storage capacity of the Memex cool. But it’s the possibility of preserving a path through knowledge that really gets me going. But notice who was doing the navigating in Bush’s world…

The user decided which connections mattered. The machine preserved them. You could follow trails created by other people, but the Memex wasn’t independently deciding which argument the user ought to make.

Bush was imagining a machine that extended human cognition. Sounds a lot like a Jupyter Notebook or Obsidian right?

That tradition would be developed further by Douglas Engelbart, Alan Kay, and others, and eventually became part of what we now call Tools for Thought.

Andy Matuschak and Michael Nielsen’s How can we develop transformative tools for thought? is one of the best modern expressions of the idea. Rather than merely speculating about how computers might help people learn, they built Quantum Country, an experimental reading environment that incorporates repeated recall into learning quantum computing. The medium is the massage. The artifact is part of the argument. Whatever cute one liner resonates with you, the point is that we’ve come a long way from hieroglyphics on a wall, and our tools need to change with the times too.

3The Tools for Thought tradition.

Maggie Appleton has made an equally important observation: tools for thought aren’t necessarily software. Writing, diagrams, notation, and social practices have extended human thinking for thousands of years. The Jupyter notebook is a tool for thought. ³

I find this tradition of tools for thought enormously compelling and timely. Reading Matuschak’s essay on how to write good prompts, after I was thinking about prompts in terms of AI, was a revelation. There are people that have been thinking about this stuff before it happened, and they can help shed light on what the best practices should be today, or at the very least illuminate the pros and cons of different approaches.

But I think we need another distinction.

If I use pen and paper to organize an argument, the pen and paper helps me think. If I use a visualization to explore a dataset, it helps me notice relationships.

When I ask an agent to investigate the dataset, decide which relationships matter, select analytical methods, weigh evidence, and propose conclusions, execute the next step, and loop over that process until I say stop… I’ve handed over meaningful discretion over the intellectual process.

Tools for Thought change what we can think. Tools for Delegated Thought change who does the thinking.

I don’t mean this as a claim about whether language models are conscious. I’m interested in the division of intellectual labor, not settling the philosophy of machine consciousness (in this particular essay anyways). Nor is it a clean distinction between products. The same agent can help me investigate a question interactively in one moment and conduct an end to end investigation independently in the next.

What matters is where discretion resides.

What matters is where discretion resides. Who decides what to investigate? Who selects the methods? Who interprets the evidence? Who chooses what happens next? Who decides when the work is done? And who bears responsibility for the result?

1. Who decides what to investigate? YouAgent
2. Who selects the methods? YouAgent
3. Who interprets the evidence? YouAgent
4. Who chooses what happens next? YouAgent
5. Who decides when the work is done? YouAgent
6. Who bears responsibility for the result?Stays with you YouAgent

Decisions with the agent: 5 of 5. Responsibility: yours.

4Older debates about automation and control.

Delegating cognition isn’t new. We’ve had accountants, advisers, assistants, researchers, and entire institutions that perform intellectual work on behalf of other people. The idea of delegating it to software isn’t new either. In 1997, Pattie Maes and Ben Shneiderman debated intelligent software agents and direct user control. In 1983, Lisanne Bainbridge had already described an irony of automation: removing routine work can leave humans responsible for exceptional situations they now have fewer opportunities to practice handling.⁴

What’s changed is the scope, speed, and accessibility of delegation. We can commission intellectual work that would previously have required expertise we don’t possess, and we can benefit from the results without necessarily acquiring that expertise.

I think that deserves a research program of its own: Tools for Delegated Thought. Not a replacement for Tools for Thought, but a companion (or perhaps a child) inquiry into what happens when intellectual work itself becomes something we can hand over.

Felix Rieseberg recently published How to Be More Ambitious: A Tutorial for Humans with Models. Felix thinks we’re still not ambitious enough about what we ask models to do, and describes four dimensions of ambition: speed, altitude, depth, and range.

Instead of asking Claude to fix individual application crashes, why not ask it to keep the application crash-free? Instead of specifying the tasks you think will produce an outcome, why not ask for the outcome itself?

I love this framing.

For years the question was whether AI could accomplish a task at all. Now we’re discovering that we can often ask for much more ambitious outcomes than we originally imagined.

7Ambition with models.

Felix also makes an observation I keep returning to: you don’t necessarily need to know which methods the best experts use, because the model may already know. You can produce legitimate work using techniques you don’t understand.⁷

This fact is extraordinary, and we shouldn’t pretend otherwise… but there is no free lunch. I’m also becoming addicted to breadth.

I can spend an afternoon learning about a database, an obscure branch of mathematics, a security problem, and a mechanical watch complication. By dinner I can ask reasonably intelligent questions about all four. It’s wonderful, and there’s a particular pleasure in knowing enough about something to have an interesting conversation. You learn the vocabulary, discover a few important ideas, and suddenly you can participate.

Then something else catches your attention, and off you go.

At some point, you have to stop discovering new things and actually understand one of them.

Breadth is easy to accumulate this way. Depth is much less accommodating. At some point, you have to stop discovering new things and actually understand one of them.

Mitchell Hashimoto, the creator of Ghostty, wrote about building a nontrivial feature with an AI coding agent. He describes reaching what he calls the slop zone, where the agent had produced an implementation containing a critical bug that neither of them could fix. He could have kept prompting, but instead he stepped back and studied the problem himself.

8Understanding the code.

His rule is straightforward: “I’m not shipping code I don’t understand.”⁸

What I like about Hashimoto’s approach is the nuance. It’s not like he refuses to use AI. In fact, he uses it extensively. He’s willing to delegate work, but he doesn’t treat a working implementation as an exemption from understanding the software he’s responsible for. I increasingly want to hold myself to a similar standard.

Mitchell even makes a carve-out that covers a lot of what Dev rel people like me do: for PoCs, demos, and experiments, his rule is suspended. But I think he is making a mistake. If the people demoing don’t understand you will have a hard time actually selling the product. Dev rel doesn’t need to have the depth that the person who is building the feature needs, but I am a big believer that in 2026 Engineers should do Dev Rel and Dev Rel should do engineering.

Not for every dependency I install or every small application I build for fun, but for the things I actually care about.

Because after playing around with AI for 7 years I’ve finally realized what I want.

I want to become an expert on Tools for Delegated Thought.

Not just agents or the software built around them. Everything that comes with it: the psychology of delegating intellectual work, the philosophy around working with machines and humans to reach a common goal, the economics of increasingly abundant intelligence, the security models governing what agents can do, how people learn, how they lose expertise, and how institutions distribute authority. I want to understand the history better than anyone, identify questions nobody has asked, build tools that make those questions concrete, and run experiments that reveal things we didn’t know. When my ideas turn out to be wrong, I want to be the person who discovers why.

Think about something like creating an email policy for a company. Let’s start with something simple. You want all your employees to be able to use AI to send emails. You don’t want your employees to send any sensitive information to email addresses outside of the company.

Sounds simple enough, right? Define your rules for sensitive information, check where the email is going, and carry on with your life.

In practice though, you are dealing with a classic precision/recall tradeoff. I can very easily create a filter that doesn’t let any sensitive information through, but it will also be very disruptive to the humans at the company. On the flip side, I can create a loose policy that never blocks anyone’s actions, but then I would be sending sensitive data outside the org. Admins are now faced with deciding exactly how much user dissatisfaction they are willing to tolerate. Make the system too restrictive, people will complain that they can’t get legitimate work done. Make it too loose, and your security team will shut you down. You need to be able to ride that line, and understand the impact across your system and people. It isn’t enough to understand how policy, tools, or python works. You also have to understand how people work, and how groups of people with different personal incentives can come together to work towards a common goal.

That’s going to require an enormous amount of breadth, but I think it is breadth in service of depth (dear reader, please call me out if this is incorrect and I’m just finding a way to weasel back into breadth!). I don’t want to talk intelligently about a thousand unrelated subjects. I want to understand one important problem so thoroughly that pursuing it takes me into a thousand different fields.

The attentive reader may have noticed that there’s a wonderfully inconvenient contradiction here. The technology making that research possible also makes it much easier to avoid doing parts of the research myself.

Suppose I can build an application in a weekend that would previously have taken six months.

What happened to those six months? Some of that time would have been wasted on boilerplate, configuration, and tedious debugging. Good riddance. Don’t let the door hit you on the way out.

But some of it might have been spent learning how the system worked, which approaches failed, why the architecture mattered, and what to do when something broke.

I think it is cope to assume all that friction was valuable. I also think it is unfair to assume none of it was.

Friction makes fire.

But sometimes you just want to be warm.

I’ve gotten into watches recently, which has given me another way to think about this. If your goal is telling accurate time, quartz watches solved the practical problem rather well. Yet people still design tourbillons, perpetual calendars, and minute repeaters because there’s something worth appreciating in how the result is produced.

Understanding the mechanics changes how you experience the watch.

Movies are similar. You can watch a film knowing absolutely nothing about cinematography or editing and have a wonderful time. Sometimes a movie is just fucking fun. But once you understand filmmaking, you begin noticing decisions you couldn’t see before.

The movie hasn’t changed. You have.

I don’t think everyone needs to become a watchmaker or a film scholar, and I don’t think every interaction with AI needs to teach us something. Sometimes I just want the result.

Those are different goals. The trouble starts when I pursue the first while convincing myself I’m accomplishing the second.

There’s another side to delegation that has little to do with whether I understand the work. It’s about who gets to decide what the agent is allowed to do.

Consider The Dictator’s Handbook, by Bruce Bueno de Mesquita and Alastair Smith. The book is about political power, and one of its central arguments is that leaders’ behavior is shaped by the people whose support they need and the institutions that determine how power is maintained.

Agents aren’t dictators, and political science isn’t an authorization specification. But the book has made me more interested in the incentives beneath the rules.

An agent follows instructions from a user. Fine. But the user isn’t necessarily the only person whose interests matter.

Suppose I ask an agent to manage my email.

I want productivity. My employer wants results. Security wants to prevent unauthorized disclosure. Customers want their information protected. The people on the other end of my emails would probably appreciate it if I gave their correspondence some actual thought.

An agent can accomplish the task I assigned it while making somebody else worse off. An eye for an eye leaves the world blind…

This is part of why I’m researching contextual access.

It’s relatively easy to say an agent isn’t allowed to send external email. You can remove that permission. But real work isn’t organized into neat categories of safe and unsafe tools.

Suppose an employee is authorized to approve loans, and their agent can call a loan-approval tool. I introduce a policy preventing the agent from approving loans over $50,000 without additional human review.

Maybe that’s an excellent policy. But take a closer look at what I’ve done: I’ve restricted what the employee can delegate. If they can approve a $60,000 loan directly, I’ve created a distinction between their personal authority and the authority they can exercise through an agent.

It’s still a decision about power, not merely a technical constraint.

That might be exactly what the organization needs. But it’s still a decision about power, not merely a technical constraint.

Now imagine the rules aren’t so straightforward. An agent wants to send information through Slack. The channel is private, but contains an external contractor. Another channel is public within the company, but everybody in it is authorized to see the material. Which message should be allowed?

The answer depends on more than the tool or channel. It depends on who’s acting, on whose behalf, what information is involved, who receives it, for what purpose, and under which organizational rules.

And what happens when the policy gets it wrong?

The agent tries to send a legitimate message. Blocked. The user changes something and tries again. Blocked. They request approval, and nobody responds. Eventually they stop using the agent or find another way to get the work done.

If enough people have that experience, somebody with the authority to change the system will decide to remove the controls entirely.

Congratulations! You’ve designed governance so annoying that the organization decides it’s better off without it. That’s the rub of thinking about how you can give enterprises AI that actually helps them.

A policy can fail because a classifier incorrectly flags an authorized action. It can also fail because the classifier correctly enforces a rule that users regard as unreasonable. Those aren’t the same failure, and they don’t have the same solution.

One is an engineering problem about detection and enforcement. The other involves institutional authority, incentives, and whether people regard the rules as legitimate.

The goal shouldn’t be to block as many actions as possible. It should be to establish boundaries that meaningfully reduce risk and that people can continue working within.

There’s another distinction here that gets lost surprisingly often: deterministic enforcement doesn’t imply correct classification.

We can build a system that consistently blocks an action when a rule says to block it. That doesn’t mean the rule made the right decision.

Suppose an agent is authorized to email a customer, but the message contains confidential financial information. We can inspect recipients, match patterns, classify content, and evaluate organizational policy. A Social Security number might be comparatively easy to detect. A confidential forecast may be much harder. A sentence that’s harmless internally might be disastrous when forwarded to a competitor.

And a second model checking the first doesn’t automatically solve the problem. The second model can be wrong too.

So I started testing it. I took 2,000 emails sampled at random from the Enron corpus, the real correspondence of a real company, and ran ten different detectors over exactly the same messages: keyword lists, regular expressions, off-the-shelf entity detectors, and several small models running on my laptop. A separate model drafted reference labels, and I reviewed some of the hard cases myself. My working rule for those became: would you share this on LinkedIn?

The results were humbling. On the 805 emails where every detector ran and the reference label was usable, the best small model agreed with the labels better than anything else, and it still caught only 35 of the 114 sensitive messages. The detectors that caught the most sensitive messages also flagged between 538 and 609 of the 691 that weren’t sensitive. Turn one of those on as a policy and you’d block most of the legitimate email in the sample. Some detectors couldn’t read more than a quarter of the messages at all, mostly because the emails were too long for them. A check that can’t read the email has to fail open or fail closed, and that choice is a policy decision somebody has to make.

I want to be careful about what this shows. The reference labels came from a model, not from people, and nearly half the sample has no usable label at all. It’s an exploratory run, not proof that any detector works or doesn’t. But it made the tradeoff concrete in a way the argument above couldn’t.

Could another model identify mistakes and suggest improvements? Do those improvements generalize to messages it hasn’t seen? How would the policies perform when users have incentives to circumvent them?

Those are the next experiments.

10Tool annotations versus actual authority.

At Arcade, I get to work on a related part of the problem: separating an agent’s ability to reason about an action from its authority to execute that action. The Model Context Protocol gives us a vocabulary for describing tools, including annotations such as readOnlyHint and destructiveHint. Those annotations are hints, not security guarantees. Actual authorization needs to be enforced at trusted boundaries.¹⁰

An agent shouldn’t be able to send email merely because it decided sending email would help accomplish a task. I don’t want to rely on the fourth sentence of my prompt to establish that boundary.

I learned this the embarrassing way. My agent was helping me debug a customer’s sign-in setup. It needed to know which of their servers handled authentication, so it registered a test app on each one to see which answered. One did. My agent had just created something on a customer’s production system.

It did exactly what I asked: find the server. I never said “and don’t touch anything,” because it didn’t occur to me that I needed to. We told their engineers and cleaned it up. My first instinct was to add a line to my instructions: customer systems are read-only. That’s just a fifth sentence. The agent never should have held the authority to write there in the first place.

But I also don’t want to design policies that strip users of useful capabilities until they become so frustrated that they disable governance entirely.

The hard part is managing both sides of that problem.

I’ve been seeing developers (and non-developers) declare that software engineering is over. Models can write the code. Agents can ship the application. Why bother learning anything?

I understand the anxiety.

People are losing jobs, experienced engineers are struggling to find work, and skills that took decades to develop suddenly seem less valuable. The existence of new problems doesn’t guarantee that the people displaced by automation will find work solving them. That’s a serious economic problem, and telling somebody worried about their family to embrace the future isn’t especially useful.

But I can’t reconcile the claim that there’s nothing left to do with what I encounter at work every day.

Holy shit, there’s so much left to do!

Writing the email is becoming the easy part.

Take something as simple as allowing an agent to send email. Writing the email is becoming the easy part. Now we need authorization, contextual policies, information classification, evaluation systems, approval mechanisms, audit trails, and ways to handle exceptions.

We need to understand which decisions agents should make and which should remain with humans. We need to evaluate outcomes beyond whether the immediate task succeeded. And we need to understand what happens to the people increasingly relying on agents to perform intellectual work. We need new admin dashboards so you monitor not only what humans are sending but what the agents are reading and sending. What happens when an agent gets phished?

That’s just email.

Making software easier to produce doesn’t make the problems it’s meant to solve disappear. Sometimes it exposes problems we could previously afford to ignore.

There’s something else I appreciate about working at Arcade. I get to spend my days using AI while regularly being forced to operate without it.

In my day to day job working with developers, I present live, answer questions, and explain technical ideas to people who may know considerably more about them than I do. Sometimes I discover I understand the subject. Sometimes I discover I recognize the right answer when a model gives it to me, but wouldn’t have been able to produce or defend it myself.

Those aren’t quite the same thing.

I helped write an academic research paper on Tool Recommendation, posted on arXiv on October 16, and I’m proud of the work I contributed: the research, analysis, and writing. I’m also aware of the areas where I relied on engineers and researchers with much deeper expertise.

That’s fine. Serious research is collaborative. What bothers me is the possibility of losing track of which parts I understand and which parts I don’t.

I don’t want to spend the next decade producing increasingly impressive things that I can’t meaningfully explain.

That’s why I built Save Point.

Save Point is an agent skill that asks developers questions about code after AI-assisted work. It reads a recent diff and constructs questions grounded in the code. You answer in your own words. If you need assistance, that’s fine, but the record distinguishes what you demonstrated independently from what you learned with help. It also takes a note from Quantum Country and revisits the material through spaced repetition. Just like Andy M created a new format with Orbit, we now need new formats to learn about information. This post from gabriel asks why every school lesson isn’t a bottom-up explainer video.

Who knows what will be the best way to learn? Will we one day have a study that shows better retention when typing than writing? Or speaking to Granola/Wispr Flow?

The idea is that recognizing an explanation immediately after hearing it isn’t the same thing as having retained the understanding.

Save Point isn’t proof that somebody knows their code. Its evaluation can be wrong, and I haven’t established that using it makes developers better. That’s another thing I want to test.

But it represents a design principle I care about: if an agent is performing more of the work, we should be deliberate about what understanding returns to the human.

I don’t only see this in other people’s work. I recently noticed I was at the top of a usage leaderboard and had no idea why. When I looked, 446,177 of my 496,703 API calls came from one lookup that a content pipeline I’d built ran every thirty minutes. I had written that schedule, shipped it, and forgotten it existed. It did exactly what I told it to, hundreds of thousands of times, and I couldn’t have told you what it was doing.

There’s a related problem I want to investigate. In the notebook example, part of what disappeared wasn’t knowledge of the finished code. It was visibility into the investigation: the failed attempts, unexpected outputs, repairs, and changes in approach.

So I’ve been thinking about building something I’m calling a Delegation Receipt.

Not a hundred pages of agent logs, and not another fucking dashboard.

Finish a coding session, run a command, and get an inspectable record of what happened. Not a hundred pages of agent logs, and not another fucking dashboard. Just the important evidence: what changed, which commands failed, what the agent tried next, which tests actually ran, and which decisions deserve closer attention.

Something you could attach to a pull request or examine before merging.

I’ve tested one piece of this already. I built Tilt, a coding agent that has to declare what it’s about to do before it touches a tool, and then audits what it actually did against that declaration. People who didn’t know what the audit had flagged labeled the same turns, and I pre-registered what would count as success. The audit caught 85% of the mismatches the people saw, but only 42% of its flags were right. By my own bar that’s a failure, so I called it one.

The more interesting number was a different one. On 60 turns where every call ran without an error, the people still found that 15 of them didn’t do what the agent said it would. On search tasks, agents declared actions they never attempted on 70% of turns. On local coding tasks it was 2%. “It ran without errors” and “it did what it said” are different claims, and most of our tooling only checks the first.

I don’t know yet whether this would improve understanding. Maybe developers would read the receipts and catch problems they would otherwise have missed. Maybe they’d ignore them. But that’s a useful experiment, and unlike an abstract argument about whether AI makes people stupid, it could produce a tool developers actually want to use.

I’ve started organizing Tools for Delegated Thought around five questions. Together they spell CADRE, from the French for frame, though the letters aren’t steps in order.

Context

asks what the agent needs to know, which information is relevant and accurate, and what it should be allowed to access.

Authority

asks what the agent can decide or do on somebody’s behalf, who establishes those boundaries, and whose interests they protect.

Delegation

asks what intellectual work we’re handing over and how much discretion the system has to choose methods and intermediate goals.

Reintegration

asks what happens to the knowledge after the work is finished. What does the human understand, and what should they understand?

Evidence

asks how we know whether the agent succeeded, what would change our minds, and how we can assess its behavior without letting it grade itself.

I don’t want these to remain philosophical questions. I’m working on things that let me investigate different parts of them.

CanAIUse.com is part of my effort to make agent capabilities and compatibility more legible to developers. Before building workflows on top of these systems, it helps to know what the available tools actually support, where they differ, and what limitations developers will encounter.

Then there’s the PB&J Test.

If you can harken back to youth and remember your elementary school science class, you might remember the exercise where you have to write precise instructions for somebody to make a peanut butter and jelly sandwich as if they were conducting a scientific experiment. “Put peanut butter on the bread” turns out to leave quite a few things unspecified.

The exercise was about how difficult it is to tell another human exactly what to do. Now we have almost the opposite problem.

What if it produces something that looks like a sandwich but isn’t edible?

We can give an agent an objective, make a sandwich, and let it decide how to proceed. But what happens when the peanut butter is missing? Can it substitute another ingredient? Is it authorized to open every cupboard? What if it produces something that looks like a sandwich but isn’t edible?

So I built a deterministic kitchen. An agent gets an objective and a set of tools, takes actions, and the kitchen independently checks what actually happened, ingredient by ingredient. I ran 1,760 episodes across four models and several versions of the same tools.

All four made the sandwich every time at every one of the simpler levels, whatever the tools looked like. The surprise came when I added a much smaller model. When the placement tool asked GPT-5 nano to choose where each ingredient went, it finished the simplest sandwich 0 times out of 30. When the tool could only put the next ingredient on top of the stack, it finished 29 times out of 30. Taking a decision away from the model made the difference. That restriction has a cost, though: the narrow tool can’t solve the harder kitchens at all, because some of them need an ingredient put somewhere other than the top of the stack. And it’s one small model on one simple kitchen, not a law.

Next comes a robot simulator. Eventually, I’d like to see a real robot make the sandwich.

The sandwich itself isn’t important. The interesting thing is the difference between producing convincing instructions for accomplishing something and actually accomplishing it, along with the decisions we delegate between the objective and the result.

Contextual Access examines another part of the problem: how agents should exercise authority across email, Slack, financial systems, and other applications. What can they do, under which circumstances, and how should the rules account for user friction, false positives, and the risk that people abandon the controls?

Save Point and the proposed Delegation Receipt examine what I think of as the return path. What did the agent do? What does the human understand? Can we improve that relationship without requiring the human to redo all the work?

These projects overlap, which is useful. PB&J involves delegation, authority, and evidence. Contextual Access requires context, authority, and evidence. Save Point addresses reintegration, but also raises questions about how to verify human understanding.

I don’t think I need one project for every pillar. I need instruments that help answer the questions.

And I want those instruments to produce evidence, not just impressive demos. A benchmark should reveal something about the systems we’re testing. A comprehension tool should help us discover whether people actually learn. A governance system should be evaluated not just on what it blocks, but on whether people can work effectively under its rules.

I’ve become increasingly convinced that this is how I want to approach research: build something real, study what happens, discover where the theory breaks, and build something better.

If Tools for Delegated Thought is going to become a serious field, it needs more than good essays.

It needs experiments that can tell us when we’re wrong.

I’ve noticed something else about myself.

I’ve struggled to write about AI under my own name. I sit down intending to produce something impressive, something that will make technically sophisticated people take me seriously, and I get stuck.

Meanwhile, I recently wrote a deeply personal essay under an anonymous identity, and the words came much more easily. I wasn’t trying to establish my expertise. I’d experienced something and wanted to understand what it meant. Writing was how I figured it out.

11Writing as thinking.

Paul Graham has argued that AI may remove the pressure that previously forced people to learn to write, even though writing is one of the ways we learn to think. I find that concern hard to dismiss.¹¹

But I’m not convinced the answer is refusing to use AI for writing.

I can ask an agent to research a topic, find sources, propose an argument, and produce a draft. I can ask it to identify weaknesses, challenge assumptions, and rewrite the prose. It can be genuinely helpful. It can also produce something that sounds impressive without being particularly thoughtful.

I’ve seen that happen in this very essay.

I’ve been working through these ideas with AI. At one point I put a draft through an AI detector, and it highlighted passage after passage.

That wasn’t scientific proof of anything. AI detectors aren’t reliable arbiters of who wrote a sentence. But reading those passages made me uncomfortable for a different reason.

I recognized the ideas. I didn’t recognize all the writing.

I had to admit that competence wasn’t what I wanted.

There were explanations that sounded polished but generic, historical references inserted exactly where you’d expect them, and transitions that explained conclusions the reader could easily have reached alone. The prose was competent. I had to admit that competence wasn’t what I wanted.

That’s a rather good demonstration of the problem I’ve spent this essay trying to describe.

I’d produced something I could plausibly publish. I agreed with much of what it said. But I wasn’t satisfied that I’d done the intellectual and editorial work required to make it mine.

So I went back. Not because the detector had proved anything, but because the experience exposed a distinction I cared about.

I don’t think real writers need to type every word themselves. Writing has always involved editors, collaborators, borrowed ideas, and tools. I also don’t think the final output is the only thing that matters.

Sometimes writing is the work. Sometimes struggling to explain something is how you discover what you actually think.

I’ve spent years wanting machines that could do almost anything, and now I’m beginning to get them. I don’t want less of that power. I want better models, more capable agents, and the freedom to build things I couldn’t have imagined attempting a few years ago.

But I also want to understand what kind of power it is, which parts become my own, and what happens when I confuse the two.

For most of computing history, we had to tell computers what to do. Now we can increasingly tell them what we mean, and they can figure out how to do it. That’s an extraordinary achievement.

It also leaves us with new decisions about what we delegate, what we understand, and what kind of people we want to become while using these systems.

And there’s one question I keep returning to.