So I wrote this talk as a way to wander into the swamp of problems and start to feel for the shapes of solutions. It turns out I have some theories about what’s wrong with our planning systems and interfaces. I just presented the first version of this talk at an internal Microsoft conference, though I plan to keep developing it and hopefully share on some bigger stages.

This talk is about collaborative planning with agents: divided worlds, boundary objects, and thicker interfaces.

But let’s first talk about Thomas Gladwin , an anthropologist who spent time between the 1940s and 1960s living among the Chuukese people in Micronesia.

These people live in a very remote set of islands in the middle of the Pacific Ocean. He was studying how they navigate the open seas compared with European navigators.

The European navigator would begin every journey by making a plan. They would plot a course from maps and general, abstract principles, trying to do most of their thinking in advance.

Once at sea, they would compare every move against the plan and work to stay on the course they had set. When something unexpected happened, they would have to revise the plan.

The Chuukese navigators work differently: they do not make plans ahead of time.

They instead begin with an objective, like reaching a certain island, and set off without a firm route.

Instead, they respond to conditions as they arise, reading the wind, waves, currents, sun, and birds and steering accordingly. They’re continuously thinking about how to reach the objective and making ad hoc decisions, constantly improvising based on the context.

I found this anecdote in the opening of Lucy Suchman ’s book Plans and Situated Actions , which I’ll reference a few times.

Suchman is a famous HCI researcher and cultural anthropologist who worked at Xerox PARC in the 80s and 90s. Her book is all about planning and communicating with machines, and despite being written in 1987, it’s still very relevant to solving our current problems with agents.

We always like to think technology moves so fast that history is almost irrelevant to us. But actually I think we in computer science have often failed to learn the lessons of the past and could benefit from revisiting a lot of theory from the 80s and 90s.

Anyway, in the book Suchman points to this anecdote to talk about what plans can and can’t do.

It’s not about whose method of navigation is better. The point is that even when you make a plan up front, it quickly becomes irrelevant once you are taking situated action in a real-world context. Everyone on the journey is reacting to their environment and making ad hoc decisions, whether they had a plan or not.

As Suchman puts it, “Plans are best viewed as a weak resource for ad hoc activity.” She says, “we all act like the Chuukese, however much some of us may talk like Europeans.”

The European mistake is to assume that once you make a plan, you simply execute it. That the map is the territory, and reality will adhere to your expectations.

In other words, as Mike Tyson says, everyone has a plan until they get punched in the mouth.

And in engineering, you usually get punched by complexity and wicked problems.

So this talk is about planning software engineering work with agents. This is my current research obsession.

For context, I am a designer, engineer, and researcher at GitHub Next , which is the R&D lab arm of GitHub. We work on figuring out what GitHub should do next, but focus on things that are riskier and further out than what the usual organisation would think about.

And I’m currently researching how we make better tools for collaborative planning with agents.

And by collaborative, I mean humans and agents in the same context, all planning together in real time.

Right now, it’s really not good.

When you or I start planning with an agent today, we’re in our CLI or desktop app of choice, alone, and we usually begin in some kind of plan mode or with the /grill-me skill enabled, and then proceed to answer 40 multiple-choice questions.

We get tired somewhere around question eight and just start picking option A, the recommended option.

Maybe because we don’t fully understand the question, because we’re being asked about something so complex that we have no way to reason about it in this interface, or because it’s outside the scope of our knowledge.

Eventually, the agent stops asking questions and gives me a huge wall of Markdown to read. Then it asks: do you approve this plan, yes or no?

There are some very obvious problems here. Especially in a CLI interface, I can’t edit the plan directly. The plan almost always has open questions in it, despite the grilling process, and I don’t have an interface for answering them.

I can’t pause on any of the questions and say, we need to go deeper on this, or ask an agent to research this, or help me prototype this. There’s no pacing to the experience.

This is not an ideal environment for making thoughtful, informed decisions. And then anything I decide, the agent treats as if it’s as written in blood.

It’s also strangely private. My coworkers and I are all making plans separately, we can’t see each other’s work. We can’t ask for each other’s opinions on these decisions. We can’t even comment on them or debate them.

This is not a sophisticated process. This is not a good process.

So, aside from my surface-level gripes about CLIs, what’s really wrong with this system?

The first problem is our European navigator approach.

We’re writing a plan for an imagined journey through a codebase and runtime. Trying to predict the best approach before encountering reality.

But we have the unhelpful twist that the planner and the traveller are not the same being. We’re in the odd position of needing to make all the important decisions up front because an agent has to go on the journey alone.

And it will need to make ad hoc decisions and take situated actions, but without the human there to help with judgement calls.

Which is hard because for the outcome to be good or useful, the human’s intent and desires need to closely align with the agent’s situated actions.

The second problem is that the current planning medium is a poorly designed environment for humans to do high-quality thinking in.

Planning right now is all walls of text. We write walls of text to the agent; it writes walls of text back.

Humans are not efficient readers. We can read about 240 words a minute, and an agent can write about 4,500, which is 19 times faster than we can read. So there’s a huge mismatch between the amount of text agents produce and the amount we can consume.

We get tired, we skim, and we miss important details. This is one reason why so many people report burnout and exhaustion with agentic work.

They’re trying to make hard choices all day while swamped in dense, hard-to-use interfaces. This is a poor medium for deep work and complex problem-solving.

A lot of why this is a difficult problem to solve boils down to humans and agents being very different kinds of beings, with very different worlds, that are only partially legible to one another.

Let’s go back to Suchman’s research for a second.

She did a famous study where she videotaped two PhD researchers trying to use a Xerox PARC copier that had an “intelligent expert help system” built into it. What we would now think of as primitive AI.

And they, of course, spent forever trying to make copies according to the instructions and failed to do so.

It’s not really a story about failed interface design, though. It’s a story about what information is available to the humans versus the machine, and their mental models of one another.

Suchman pointed out that the copier didn’t have access to most of the information about what was going on in the human world, such as the researchers hesitating, debating, looking at instructions, making gestures, and stating their expectations of what was happening.

It could only see button presses or them opening the paper tray. And in the same way, the humans could only see messages printed on the screen, but not the internal state of the machine or program design.

She says it’s as if both sides were looking at each other through a keyhole.

This doesn’t feel all that different to me from how we interface with agents.

Of course our interfaces have come a very long way since the days of physical buttons and small screens. I don’t want to downplay the difference between that and being able to dump huge amounts of natural-language transcriptions into an agent.

But it does still feel like posting little text messages through an input box.

Like we’re passing notes between these two very different worlds.

Humans live in this world of embodiment and physical space and rich visuals, colour, gesture, emotion, voices, expressions, society, and cultures. All of which agents are terrible at understanding.

And agents live in a world of vectors and weights and rewards and statistical probability and gradient descent.

And both of these worlds are rich and complex in their own right, but neither of them is fully legible to the other. We struggle to understand what’s happening inside agentic systems. Interpretability is not a solved problem.

I should acknowledge agents can get more than text from us. They can understand and create images and audio and video. But the language model part of agents is still the dominant medium. And we know language doesn’t fully capture human knowledge.

Which is why plenty of people are currently trying to teach agents to build world models and interpret physical reality. But until we figure that out, the challenge is to get human intent, decision-making, and expertise passed to an agent that sees the world through very alien, language-centric eyes.

I think this is best explained by trying to imagine your ideal way of planning a feature or product, with both people and agents, beyond what our current interfaces are capable of.

A small version of this desire would have me and a coworker on a call, working together with agents.

And the agents can see us using our webcams, in real time.

See our gaze, facial expression, and hand gestures. Hear what my coworker and I are saying to each other, as well as our pacing, pauses, and the emotional tone in our voices. As well as what’s on our screens, where we’re clicking and hovering.

They don’t have to ask us how they’re performing or whether we like the results. They can see it and pause, redirect, or try to fix the problem.

This feels relatively far from what we currently have, but still realistic within a couple of years.

But that dream isn’t even the actual ideal. It’s a constrained one that’s still plausible within our current interfaces.

What’s my true ideal environment for problem solving, without tying myself strictly to current constraints?

For me, it would be in person, around a whiteboard with coworkers. Talking, pointing, drawing, gesturing, noticing confusion, excitement, tension, and silence. Making eye contact to direct attention in the room. Multiple laptops open running prototypes. Projecting screens onto the walls so we can access computational outputs as well.

This is something like the ideal human context for thought. Agents would not understand most of it. It doesn’t have any of the right inputs.

One solution: cameras, sensors, microphones. Make agents able to see and hear us. Watch our hands, track our gaze, and follow us around a whiteboard.

This is a very ubicomp dream and there are plenty of reasons we don’t have it.

Both the small and large versions of the dream I’ve just painted are filled with complex challenges. The amount of data the agents would need to process in real time, to store, and to understand is immense. Not just the physical inputs, but the social context, roles, and backgrounds. It is awash in complex problems. I don’t know that we actually need it to achieve what we want.

We don’t need to fully bring agents into our world…

…or fully understand theirs

We just need effective ways to collaborate between the two worlds.

What we need is effective boundary objects .

The theory of boundary objects comes from sociologists Susan Leigh Star and James Griesemer’s 1989 paper, Institutional Ecology, “Translations” and Boundary Objects , about the founding of Berkeley’s Museum of Vertebrate Zoology .

When the museum was being founded, it succeeded in bringing together lots of different social groups with different cultures, beliefs, training, and priorities to create it: biologists, trappers, funders, and university administrators.

All able to effectively collaborate through boundary objects.

Specimens, labels, field notes, drawings, and maps – they inhabited each of these social worlds slightly differently.

They meant different things to different people. The biologists and the funders read the maps differently, but had a shared understanding of the concept of California.

This is what effective boundary objects need to do: adapt to the local needs of each group and provide the right information to the right people, allowing them to create a shared reality.

Our current boundary objects with agents are things like plans, prompts, skills, and AGENT.md files. And they work okay…

…but they’re mostly designed for the agent’s way of seeing the world; they optimise the agent’s performance.

We currently show humans and agents the exact same Markdown files and expect them to work equally well for both of us. Agents can happily consume walls of text, stacks of tool calls, and debug logs. But for humans, reading all of that is slow, tiring, and expensive.

We are making humans adapt to the agent’s ideal ways of working, rather than making objects that adapt to both sides.

Another way to put this is that our interfaces between humans and agents are very thin.

There’s not a lot of translation between what humans see and what agents see.

I think they need to get thicker in the sense that we need to use the relatively cheap and infinite labour of agents to construct rich layers of translation that serve humans really well.

The agent is not the prioritised party in this interaction. We are.

The agent should be doing far more labour for human benefit.

So, what would thicker interfaces and better boundary objects look like?

First, they need to be optimised for human understanding and legibility. That means moving beyond text and making use of visual, spatial, interactive, and social ways of thinking.

Text is obviously brilliant. It’s precise, adaptable, and very good at expressing ideas. But it’s also a narrow channel for all the complex things we need to see and understand in software engineering.

Writing is only about 5,000 years old. But our complex visual systems go back more than 500 million years.

We’re evolutionarily designed to move through physical environments, track things on the horizon, notice colour and movement, judge distance, arrange objects in space, and compare shapes. Most of this happens quickly and automatically.

This is why visual representations work so well. We can map complex data to colours, shapes, and space to make things visible and tangible, showing us things we couldn’t see before.

It moves the work out of working memory and into the world.

And we have lots of visual languages for doing this.

Charts reveal comparisons. Maps show movement through space. Timelines make sequence and overlap visible.

Each representation reveals a different kind of structure. And software engineering has a moderate history of taking advantage of this.

For example, state machines.

And architecture diagrams.

And I’m seeing people explore novel, visual ways of showing agent activity, like Mindwalk , which traces an agent run, showing what files it touched in a codebase.

The best thing about this demo is it’s interactive. You can click around. Humans, of course, think best by doing. Point and gesture; we move things around to test what happens. We let feedback from the world update our understanding.

Ideally it would also be multiplayer! This should have lots of coworkers in here with us. We’re social animals and learn best when we’re developing ideas with other people, questioning each other, and building up shared understanding.

But most agent interfaces flatten all of this into a solo stream of text. So text is doing too much work while our visual, embodied, and social abilities sit mostly idle.

So better boundary objects should make relationships visible, let us manipulate the plan directly, and give people a shared thing to point at and discuss. That’s a concrete way to reduce the cognitive load of working with agents.

The second way to improve these objects is to solve our European navigator problem.

By the time we hand the plan over, it should already have made meaningful contact with the important parts of reality.

Luckily, this is not a nineteenth-century sailing expedition and we can explore the terrain ahead of time.

Planning agents already do this a bit: they search the codebase, read files, and trace dependencies. It gives them a useful aerial view and catches obvious issues.

But they currently stop at observation. They predict which implementation will work without making prototypes, running them, or comparing them based on outcomes.

They could instead do more upfront legwork by splitting the work among subagents on multiple Git branches, implementing many approaches at once, and then evaluating the results.

This brings reality into the planning process, while the human is in the loop and can help make informed decisions.

I’m sure you’re thinking “well, that’s going to get expensive.” Within Next , we have the philosophy that in order to invent the future you have to live in it. Pretend that agent labour is functionally free; eventually it’s going to become cheap and plentiful, so we should explore as if it is.

So what does this look like in practice? Here is a planning agent in a terminal, helping me develop a set of consistent shadows for my design system.

It’s offering me three options: do you want the shadows to be crisp, soft, or pronounced?

The way this decision is presented to me, in text in a CLI, makes it impossible to make an informed decision. I don’t know what the current shadows in my app look like, and I don’t know what each of these options it’s offering me is going to look like.

Obviously, for the shape of this problem, I need an interface more like this.

First, this is connected to my live app so it’s showing me the actual shadows currently in the system.

Then I can directly manipulate the qualities of these shadows and see the results live. Maybe I want to change the colour or intensity of the shadows. When I’m happy with them, I can save that decision back to the plan.

Similarly, let’s say I have these cards with a little animation when I hover over them. I should have a bespoke interface that helps me adjust the easing and speed of it.

Note that the number of options available to me in this interface is exponentially more than three.

These are the kinds of interfaces that meaningfully enable human decision-making. The interface should be grounded in reality (my codebase) and let me manipulate it to come to the right decision.

Of course, visual problems naturally lend themselves to interactive interfaces, so what about more abstract logic problems?

I was recently debugging some mess with a video player and a reducer and answering increasingly complex questions in the CLI. We clearly needed to rearchitect it. Again, this was not the right interface for the problem.

But a state machine would let me see and explore all the possible states of the component, see what happens when I add different transitions, and find out what’s happening with the buffering loop.

We already have good conventions for programming interfaces like state machines. We can now get agents to build this kind of exploration on the fly to help us solve a particular problem in the moment.

This brings the important parts of reality forward into the planning process, rather than letting the agent encounter them later, while it’s on the journey alone.

One last demo: I was working on some retry logic, and the agent asked me to choose between specific syntax like an options object, a wrapper function, or a client policy.

This is exactly the kind of thing that it’s hard to reason about the repercussions of from this interface.

This is a good example of when we can just have subagents split up onto separate branches and build all three options, evaluate the results, and report back to us.

So I had the agent try all three and then make an interactive report on some key metrics like how well the solutions fit each call site and the blast radius.

And the visualisation of these options reveals so much more. It shows that option A covers all 60 call sites. Most changes are mechanical, but eight need a judgement call. Option B also covers all 60 call sites, but 16 silently change their behaviour. And option C initially seems promising because it’s only 14 changes and they’re all mechanical. Until you realise the other 46 call sites are unsupported.

It also gave me some measurable metrics like the recovery P95 and the amplification that can help inform this decision. These all help us see that Option A is clearly the right choice.

The challenge between us and this more beautiful world of working in these rich interfaces is that agents aren’t good at making visual explanations right now. Certainly not without a lot of hand-holding from me and essentially designing all of these examples myself.

And secondly, we’d need to be strategic about inference time here so I’m not waiting ages for these explorations; we’d need to have agents work in parallel, five steps ahead, and make this while I’m answering other questions.

These kinds of rich, interactive plans are what I’m currently exploring in a project called Chopin . This is a multiplayer, real-time planning prototype that my coworker Krzysztof and I are making.

It’s currently a very basic proof of concept and exploration space.

You have your coworkers and agents writing plans together in a nice Markdown editor. But one that includes lots of interactive visuals. It’s built with MDX.

I didn’t touch on the social piece much in the demos, but a key part of having better decision-making interfaces is that your coworkers can see them too, debate them, and decide collectively.

You can see here I’m answering a decision, and then it records that I made this decision at this time and date.

If you want to read more about Chopin, we’ve published a writeup with our initial research and more demos on the GitHub Next site.

So let’s wrap up and review what we learnt:

• Plans orient action. They cannot predict the whole journey.
• Humans and agents do not need shared understanding. They need good boundary objects and thick interfaces.
• Make visual, interactive, and social boundary objects.
• Improve the conditions for humans to think within. The human is the preferential being. The agent can and should do 1000x more work to make the human more effective.

Things to ask yourself in whatever you’re building:

• Where am I exposing a human to an agent’s way of seeing? What translation layers could the agent build to solve that?
• How can I optimise the environment for human understanding and deep thinking?

Thank you for reading! Look up GitHub Next for more of our research. And read our piece on GitHub Chopin to learn more about that project.