Last month we talked about people handling difficult moments well, and here are 10 of my favorite stories you shared.

1. The long-winded questioner

Back when Doctor Who rebooted, I was at a science fiction convention that had a fan panel on it, with me as one of several panelists. The convention didn’t anticipate the enthusiasm for the topic and put us in a small room that quickly became standing room only. I was not assigned to be the moderator, but when the moderator didn’t show up, I volunteered to take the role, which essentially turned me into a traffic cop for calling on audience members. The first thing I did was tell the packed room that I wouldn’t be calling on anyone a second time until everyone had had a chance to be heard. I also told everyone that they needed to keep their questions brief and to the point.

I recognized someone in the front row who was notorious for asking question after question and turning them all into long-winded rambles, so I made sure to call on him first, cut him off once it sounded like he’d gotten to the actual question, then spent the rest of the panel telling him, “You already were called on” every time he tried to interject.

Many people thanked me once it was over.

2. The reproach

I used to work at a small-ish creative agency, where our owner/CEO was quite involved in the day-to-day operations. One of our clients was a pretty rude guy, talking very condescendingly to most of the project team – especially the more junior members. A few minutes into a meeting in our office with about 10 team members, he was in a particularly dick-ish mood.

Our CEO asked him to step outside the meeting room with him for a moment. Of course, we all eavesdropped and heard most of the conversation. Our CEO said something to the effect of: “I’m sensing a lack of respect here. We want to continue working with you, but if you want the best out of this team you’re going to have to treat them more as partners with shared goals. Can we do that, or would you prefer to end our engagement?”

The client apologized to the room, and we had a much better working relationship going forward. It taught me a valuable lesson that just because a relationship is weighted in one direction, it’s OK to stand up for yourself and your team.

3. The shaming

At a concert, two people in the row in front of me got in a dispute and it was escalating. They were standing and shouting in each other’s faces when an usher, who couldn’t have been more than 20 years old, stepped in and told them to knock it off.

“Really? You’re going to get into a fight at a Maroon 5 concert? Really??” He shamed them into submission.

4. The contract renegotiation

I worked in IT supporting a Fortune 500 company with a real-time web application accessed by 20,000 people. We had a series of unfortunate outages over the course of a month. To complicate matters, our lead system admin was dealing with his wife’s terminal illness, so every outage took us longer than normal for the rest of the team to resolve.

During a client meeting, a VP was raking us over the coals, just berating us non-stop. He eventually said, “Every hour you are down costs us a million dollars.” To which our leader responded, “Then we aren’t charging you nearly enough, and our pricing will reflect that in our upcoming renewal.” That ended the conversation. And yes, they renewed with a price increase.

5. The trick

Many years ago, I was a supervisor at a coffee shop. I had one bad employee, “Jeff,” who would disappear off the floor, mess up tasks so he wouldn’t have to do them (he wasn’t allowed to make coffee. At a coffee shop.), and frequently brag about how little he had done during his shift. And as he bumbled around doing nothing, he got in everyone else’s way, making everything harder for the rest of us. I do not know why he wasn’t fired, but he wasn’t, and we were stuck with him.

One day I told him, “I’m not going to assign you any work today, I don’t care what you do this shift. But you have to look like you’re busy every single time I look at you. You don’t have to be doing anything productive, but if you don’t look busy, I’m gonna make you clean the drains.” (The worst, dirtiest, smelliest maintenance task we had, which everyone avoided like the plague.) Jeff was gleeful at the idea of a full shift of supervisor-approved slacking.

The thing was, Jeff was not clever enough to look busy without actually being busy. He moved slower than a good employee would have, but Jeff was more productive that day than he’d ever been – he prepped coffee beans, he cleaned the cafe, he restocked shelves, he took inventory. All of it grinning from ear-to-ear because in his mind, he wasn’t working, he was just “looking busy.”

I was able to use that trick a few more times, and each time Jeff thought he was getting away with highway robbery. I moved to a different store not long after, but I have always been a bit proud of tricking Jeff into actually doing his job.

6. The junior analyst

Where I work, a lot of program managers have a reputation of being overbearing, inflexible, and generally the sort who expect people to bend over backwards to meet their expectations. There was one program director in particular who was notoriously one of the worst. He would frequently belittle people, raise his voice, pound on the table to accentuate his words, etc. He was definitely on a power trip, considered scary, and most people tried to appease him to his face and then complained about him behind his back.

Enter Alex, a junior pricing analyst who had about two years of experience and had just joined the program. We were in a program status call and Director Scary Chihuahua started laying into Alex. When he was given a moment to respond, Alex took a deep breath and calmly said, “Sir, you cannot speak to me that way, and I will not tolerate this kind of treatment.”

Director Scary Chihuahua immediately changed his tone, apologized, and continued in a respectful manner for the rest of the meeting. It didn’t last of course, and he’s still a scary chihuahua, but Alex is forever my hero and that of many others on the call that day.

7. The redirection

I was on a team call with a client and the client started out by absolutely ripping into the person managing the account, to the point that they were saying stuff about the manager’s personal integrity. It was incredibly unprofessional of the client, to say the least, and awkward for everyone who was expecting a marketing meeting. I would have been livid and the manager probably was, but she just very calmly said, “I hear your feedback, but this isn’t the proper venue, and I suggest we focus on the topic at hand and we discuss this offline.” And the meeting continued.

8. The serious attention

I had to contact a customer service representative at work because something had been promised that hadn’t happened. I don’t remember the specifics, but I do remember it was a Big Deal At Work, and I remember when I got the customer service rep she said, “I am so sorry this happened. You have my complete attention. How can I fix it?” I felt so HEARD! I had such confidence that she would get it resolved! That was 20 years ago, and I still say, “You have my complete attention” when I want someone to know I’m taking them very seriously.

9. The apology

Some years back, a student went off on me over something so minor I honestly can’t even remember what it was. I defused the situation, as one does, and let it go.

The next week, that student came to office hours, apologized sincerely, and said, “I don’t know what got into me, and that’s not the kind of person I want to be.”

We made up then and there. I praised the student for the level of responsibility and maturity they were displaying, and said that if they needed a recommendation for anything ever, they should come to me.

10. The second draft

A friend and classmate from law school was an associate lawyer at Big Law Firm working on a litigation matter for Big Scary Partner. One day, Big Scary Partner threw a copy of a brief my friend had drafted across the room yelling, “This is the worst piece of shit I have ever read!” My friend calmly responded, “Well, it can’t be the WORST piece of shit you ever read because that’s what you said last week about the first draft.”

Big Scary Partner’s demeanor didn’t completely change after that, but he did treat my friend a lot better and they worked together for years.

The post the coffeeshop manipulation, the Maroon 5 shaming, and other people handling difficult moments well appeared first on Ask a Manager.

Article URL: https://blog.trailofbits.com/2026/09/21/saml-a-fractal-of-bad-design/

Comments URL: https://news.ycombinator.com/item?id=49806335

Points: 111

# Comments: 59

Read Tokens, Please!

About three months ago, I bought the Onyx BOOX 25.3” Mira Pro Color, an e-ink monitor for desktop use. I’ve used it as my primary monitor since, and I’ve had a lot of questions about it. This is my experience report, from the perspective of a working, still mostly typing, programmer.

This is not a sponsored post, and it is not a product review. I wrote a very similar post about the Daylight DC-1 last year.

As explained in last year’s post, the reason I persist with these monitors is because it makes me energetic and happy. Sunlight, direct or indirect, helps me stay clear and focused during my workday. I find spaces illuminated by natural light beautiful and inspiring.

I’m not going to recommend that you buy one of these devices. They’re expensive, about $2000, and the experience is quite different from LCD. Even if this looks cool, it seems to me very possible that most people would not like it in practice. With that said, I am happy with it, and I’ll probably keep investing in these tools as they get even better with time.

Using the Mira Pro as a primary monitor is a continuation of the experiments with my e-ink tablets and Termux as coding environments. But now, with far fewer compromises. I’m running my regular NixOS environment on my work laptop. No SSH and tmux needed, no Android terminal emulator to customize.

What I have done, though, is spent quite some time on making my system more suited for this monitor. The Mira Pro does not work well with dark themes. In fact, it only works well with high contrast light themes.

Luckily, I’m bent towards minimalism, so I already used near-monochrome themes, relying more on typographic syntax highlighting rather than coloring. I now have custom themes for Neovim, Zed, and Ghostty with a few vivid colors for things like selection, comments, and constants. Otherwise it’s largely black on white.

It’s trickier with other applications. In Firefox, I’ve started using the high contrast setting. That works pretty much like an inverse of DarkReader. I now run Spotify in the browser in order to avoid its dark theme.

The monitor has a clunky menu system with which you can change rendering modes; things like contrast and speed. I found an open-source reverse-engineered NodeJS package that I use with Hyprland keybindings to easily change rendering modes and manually refresh. No need for the built-in menu.

In practice I use two modes:

Reading:

This mode renders colors most vividly and text sharply, but typing with it is agony. I use it when reading text documents, web pages, or code diffs.

Writing:

This is by far the most commonly used mode, which compromises colors and sharpness for way better latency. I use this for everything in the terminal, chat, general web browsing, and probably most other things not covered by the reading mode.

See the following photos for a close-up comparison:

What about latency? Here’s the two short clips of me typing with the reading and writing modes:

Ghosting? In my writing mode it’s minimal. It really doesn’t bother me.

About the color panel: I don’t like it very much to be honest. It was the only version of the Mira Pro available from the Swedish retailer at the time, so I went with it. I think I would’ve been happier with a monochrome panel, because the coloring technology makes it considerably darker.

Here’s a comparison between the Palma 2 Pro (using a similar but smaller Kaleido color panel) and my old Tab Ultra (with a monochrome panel):

Unless the room has great diffuse lighting, natural or otherwise, the color panel does require some backlight. In direct sunlight or outdoors it works without. I might spend more time optimizing the lighting in my office to make this work during the winter months.

So, what’s to make of it? Personally, I enjoy using this monitor a lot, even if it’s not perfect. Should you buy an expensive 25” e-ink monitor? I cannot say. But if you do, let me know how it works out.

My custom themes and keybindings can be found here.

Fifteen years ago, when some colleagues and I were building Heroku’s V3 API, we set an ambitious goal: the public API should be powerful enough to run our own dashboard. No private endpoints, no escape hatches.

It was a stretch, but it worked. A new version of the company’s dashboard shipped on V3, and an unaffiliated developer who we’d never met before built Heroku’s first iOS app on it, without a single feature request sent our way.

The first wave

Our dashboard-on-public-APIs-only seems needlessly idealistic nowadays, but it was an objective born of the time. The year was 2011, and the optimism around the power of APIs was palpable. A new world was opening up. One of openness, interconnectivity, unbounded possibility.

And we weren’t the only ones thinking that way:

• Only a year before (2010) Facebook released its original Open Graph API, providing immensely powerful insights into its platform data.

• Twitter’s API at the time was almost completely open. You didn’t even need an OAuth token — just authenticate on API endpoints with your username/password and get access to just about anything.

• GitHub was doing really impressive API design work, providing an expansive, feature-complete API with access to anything developers could need, and playing with forward-thinking ideas like hypermedia APIs/HATEOAS.

You can still find traces of this bygone era, standing like some cyclopean ruins from a previous age. Hit the root GitHub API and you’ll find an artifact over a decade old — a list of links that were intended to be followed as hypermedia:

$ curl https://api.github.com | jq

{
  "current_user_url": "https://api.github.com/user",
  "current_user_authorizations_html_url": "https://github.com/settings/connections/applications{/client_id}",
  "authorizations_url": "https://api.github.com/authorizations",
  "code_search_url": "https://api.github.com/search/code?q={query}{&page,per_page,sort,order}",
  "commit_search_url": "https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}",
  "emails_url": "https://api.github.com/user/emails",
  "emojis_url": "https://api.github.com/emojis",
  "events_url": "https://api.github.com/events",
  ...

This wasn’t a pre-planned, stack-ranked feature that a product team spent half a year putting together. It was one or two early engineers who got really excited about an API idea, and shipped it, probably without even asking for permission.

Part of the push for open APIs was simple good will towards the rest of the world. The engineers building them were brought up in the earliest days of the internet, steeped in its original counterculture, and had an innate bias for radical openness.

There was also a feeling from the companies involved that the APIs would be beneficial for their bottom lines. Users and third parties would use APIs to supplement the core product with add-ons and extensions that’d drive growth and increase product retention and satisfaction.

Sites like the now defunct ProgrammableWeb popped up to discuss and catalog the newly appearing APIs, and the “programmable web” wasn’t only a website, it was a principle.

In the near future, all platforms would be API-first, providing full programmatic access and opening a new wave of interoperability across the web that’d let any service talk to any other service and massively accelerate the scope and reach of the internet. APIs would help expand everything from freedom to communication to commerce. An overwhelming force for good in the world.

API winter

Of course, it didn’t last. The programmable web went through a phase of expansion, reached its maximum extent, and began to contract.

• Twitter’s famous API, which used to be an API tinkerer’s dream, leveled off and began to dip as the company struggled to find ways to generate revenue. New features no longer got first-class API treatment. Access to the firehose was closed. Third-party Twitter clients were restricted and eventually locked out.

• The power of Facebook’s Graph API was hugely constricted post-Cambridge Analytica where a single rogue app was able to suck up data on millions of users and put it up for sale. Strict app review procedures were implemented. The API went from open access to a walled garden.

• Even more extreme, Instagram’s previously public API was deprecated totally. Realizing they had a real money maker on their hands, they saw no reason to share ad revenue with anyone else. Use Instagram through the first-party app or not at all.

• Even APIs like GitHub’s that stayed quite open had to crack down to a degree. Endpoints became authenticated by necessity and aggressive rate limiting was put in to curb abuse and reduce operational toil. And even when APIs were still largely accessible, using them to build a full-scale third-party app became more difficult as limiters flattened heavy (even if legitimate) use.

The rationale for why APIs were being declawed or disappearing completely varied—abuse, monetization pressure, competitive risk, privacy, etc.—but the pattern was clear. Walls were going up across the world.

APIs didn’t disappear, but it was a cold winter for them. The expectation of an API became more limited to developer-focused platforms whose users paid them — Stripe, Twilio, Slack, etc. When new consumer products appeared on the market (e.g. TikTok), no one expected them to have much in the way of an API.

The coming second wave

For many years this was the status quo. If you were using Twitter, you’d use it from Twitter.com. Facebook, from Facebook.com. Instagram or TikTok, from their respective iOS/Android apps. Developer products like GitHub and Stripe continued strong, but elsewhere, APIs weren’t enough of a competitive advantage for anyone who didn’t have one to suffer.

But around mid-2025, the world changed. The last half year especially has been distinguished by the rise of indescribably powerful LLMs, which now dominate discourse as the most useful new tool in a generation.

They’re already useful enough as incredible trivia machines or code generators, but they really start to shine when they integrate with things. It’s pretty neat having one generate a valid Kubernetes configuration for your new app, but it’s really neat watching it provision an EKS cluster via awscli and send out its first production deploy on your behalf.

Suddenly, an API is no longer liability, but a major saleable vector to give users what they want: a way into the services they use and pay for so that an agent can carry out work on their behalf. Especially given a field of relatively undifferentiated products, in the near future the availability of an API might just be the crucial deciding factor that leads to one choice winning the field.

Picking my future bank

Let’s think about banks. I have a couple bank accounts, each offering a standard set of features largely unchanged since the 60s. If I call them, they’ll send me some checks. I can request a transfer between two internal accounts and they will transfer the money … in 1-5 business days. Nowadays, they even offer ultra-modern features (from 2010) like gasp, MFA, just as long as it’s through a provider that’s paid them off (Symantec VIP). Suffice it to say, they’re comfortable in the status quo. My banks do not have good APIs.

So far this has worked out okay for them. People aren’t known to migrate banks often, and even if they did, regulatory moats make new incumbents rare.

But in the modern age, can it last? When I want to move $100 from one bank to another, my banks put me through a humiliating ritual of logging into both accounts, and bypassing multiple security checks and captchas before I can perform any operation. All this despite me having just logged into both accounts from this exact location and biometrically-secured computer the day before.

The world I want is to instruct an LLM: “move $100 from Wells Fargo checking to Charles Schwab brokerage” and it will just happen. And to be fair, LLMs are already so absurdly good at reverse engineering things that this might already work today. But you know what’d work better? If both banks shipped with APIs, LLM-friendly usage instructions (through MCP or the like), and a strong auth layer to give me confidence that the whole process is secure.

If I were choosing a bank today, some considerations would be the same as they’ve always been—competent security, free checking, no foreign transaction fees—but I’d also futureproof the choice by picking one that’s established technical bona fides by providing an API. Even if I’m not quite ready to trust my banking credentials to an agent quite yet, I assume that this day is coming.

Ubiquitous again

Now apply the same principle to every service you use during the course of a week, or ever:

• Online marketplaces: Robot, schedule my normal Amazon Fresh order for the first available slot tomorrow morning.

• Office co-working: Robot, book me a desk at Embarcadero Center today.

• Ski resorts: Robot, buy me a day pass for tomorrow and load it to my resort card. Confirm the price with me first.

• Restaurants: Robot, put in my usual lunch order at Musubi Kai. Get me the unadon!

Where wouldn’t you want an API?

Forecasting the future is infamously hazardous, but based on the adoption patterns of myself and the people around me, I expect the demand to interact with services through LLMs is going to be overwhelming, and services aiming to provide a good product experience or which face competitive pressure (i.e. someone else could provide that experience instead) will offer APIs.

I used to wish that we’d gone down an alternative branch of web technology and adopted a protocol like Gopher) so we’d have a more standardized web experience instead of every product you use producing its own unique UX, most bad. I think we will see more standardization, just not in the form I expected. The convention of the future will be human language, fed into what looks a lot like a terminal, and fulfilled via API.

On behalf of people

Notably, this is different than the first wave of APIs that I described above. Instead of APIs being to offer infinitely flexible access for inter-service communication, scrape data, or build apps on top of someone else’s platform, their primary use will be to fulfill requests on behalf of a primary user. Exactly like what they’d be doing through a first-party app, but in a programmatic way.

It may seem like a subtle distinction, but there are considerable differences. The second model better incentivizes APIs to exist:

• APIs aren’t for building a product that aims to displace the offerings of the underlying platform, but rather for giving users an alternative way to access it.

• Security models are simplified because they’re the same ones used by the product itself. Users have the same visibility that they’d have through a first-party app, and no more.

• Aiming to support access patterns for a single person, platforms can rate limit much more aggressively to curb expenses and operational problems associated with offering an API.

APIs should aim to provide a little more leeway than they would for a human, but only nominally so. An agent acting on my behalf should be able to occasionally poll LinkedIn for old colleagues that I should be reconnecting with and send them connect requests, but if someone’s set up their ClawBot to scrape the entire social graph on their behalf, platforms should feel more than free to throttle the hell out of them and give them a strike towards a permanent ban.

Slack’s rate limits are a good example of this, supporting numbers like 50 channel or 100 profile reads per minute. You can’t build a multi-user app with 50 channel reads per minute, but it’s plenty for a single user to access their own account.

Limits of the model

While can expect many products and services to offer APIs for good agentic interoperability, it won’t be forthcoming everywhere.

Don’t expect much out of Instagram, TikTok, or other platforms that power themselves with ads. Neither from monopolies that won’t feel any serious pressure to change — you won’t be reliably paying your Xfinity bill via agent anytime soon.

Hints of the future, today

In this section I figured I’d call out a few services that are already pulling this future forward:

• As I was in the middle of writing this essay, I got a note from Basecamp that they’d revamped themselves for LLM accessibility, including new API, new CLI, and bundled skill to instruct agents on their use.

API spring

Fifteen years ago, us API maximalists thought that APIs were going to eat the world, ushering in a new paradigm of interoperability that would vastly expand our capabilities as users, and even change the world for the better.

What we got instead was an API winter. As useful as APIs were in some situations, that usefulness was outweighed by concerns around revenue, privacy, and abuse.

But as scary of a thought as it was that this might be the end, it wasn’t. We’re at the beginning of a new spring of APIs that’ll appear to support use by agents acting on behalf of people. As this mode of operation gets more popular, expect the availability of an API to be a competitive edge that differentiates a service from its competitors. The result will be a global proliferation of APIs and expanding product capability like never before seen.

If you haven’t been living under a rock, you will have noticed this week that a project of my friend Peter went viral on the internet. It went by many names. The most recent one is OpenClaw but in the news you might have encountered it as ClawdBot or MoltBot depending on when you read about it. It is an agent connected to a communication channel of your choice that just runs code.

What you might be less familiar with is that what’s under the hood of OpenClaw is a little coding agent called Pi. And Pi happens to be, at this point, the coding agent that I use almost exclusively. Over the last few weeks I became more and more of a shill for the little agent. After I gave a talk on this recently, I realized that I did not actually write about Pi on this blog yet, so I feel like I might want to give some context on why I’m obsessed with it, and how it relates to OpenClaw.

Pi is written by Mario Zechner and unlike Peter, who aims for “sci-fi with a touch of madness,” ¹ Mario is very grounded. Despite the differences in approach, both OpenClaw and Pi follow the same idea: LLMs are really good at writing and running code, so embrace this. In some ways I think that’s not an accident because Peter got me and Mario hooked on this idea, and agents last year.

What is Pi?

So Pi is a coding agent. And there are many coding agents. Really, I think you can pick effectively anyone off the shelf at this point and you will be able to experience what it’s like to do agentic programming. In reviews on this blog I’ve positively talked about AMP and one of the reasons I resonated so much with AMP is that it really felt like it was a product built by people who got both addicted to agentic programming but also had tried a few different things to see which ones work and not just to build a fancy UI around it.

Pi is interesting to me because of two main reasons:

• First of all, it has a tiny core. It has the shortest system prompt of any agent that I’m aware of and it only has four tools: Read, Write, Edit, Bash.
• The second thing is that it makes up for its tiny core by providing an extension system that also allows extensions to persist state into sessions, which is incredibly powerful.

And a little bonus: Pi itself is written like excellent software. It doesn’t flicker, it doesn’t consume a lot of memory, it doesn’t randomly break, it is very reliable and it is written by someone who takes great care of what goes into the software.

Pi also is a collection of little components that you can build your own agent on top. That’s how OpenClaw is built, and that’s also how I built my own little Telegram bot and how Mario built his mom. If you want to build your own agent, connected to something, Pi when pointed to itself and mom, will conjure one up for you.

What’s Not In Pi

And in order to understand what’s in Pi, it’s even more important to understand what’s not in Pi, why it’s not in Pi and more importantly: why it won’t be in Pi. The most obvious omission is support for MCP. There is no MCP support in it. While you could build an extension for it, you can also do what OpenClaw does to support MCP which is to use mcporter. mcporter exposes MCP calls via a CLI interface or TypeScript bindings and maybe your agent can do something with it. Or not, I don’t know :)

And this is not a lazy omission. This is from the philosophy of how Pi works. Pi’s entire idea is that if you want the agent to do something that it doesn’t do yet, you don’t go and download an extension or a skill or something like this. You ask the agent to extend itself. It celebrates the idea of code writing and running code.

That’s not to say that you cannot download extensions. It is very much supported. But instead of necessarily encouraging you to download someone else’s extension, you can also point your agent to an already existing extension, say like, build it like the thing you see over there, but make these changes to it that you like.

Agents Built for Agents Building Agents

When you look at what Pi and by extension OpenClaw are doing, there is an example of software that is malleable like clay. And this sets certain requirements for the underlying architecture of it that are actually in many ways setting certain constraints on the system that really need to go into the core design.

So for instance, Pi’s underlying AI SDK is written so that a session can really contain many different messages from many different model providers. It recognizes that the portability of sessions is somewhat limited between model providers and so it doesn’t lean in too much into any model-provider-specific feature set that cannot be transferred to another.

The second is that in addition to the model messages it maintains custom messages in the session files which can be used by extensions to store state or by the system itself to maintain information that either not at all is sent to the AI or only parts of it.

Because this system exists and extension state can also be persisted to disk, it has built-in hot reloading so that the agent can write code, reload, test it and go in a loop until your extension actually is functional. It also ships with documentation and examples that the agent itself can use to extend itself. Even better: sessions in Pi are trees. You can branch and navigate within a session which opens up all kinds of interesting opportunities such as enabling workflows for making a side-quest to fix a broken agent tool without wasting context in the main session. After the tool is fixed, I can rewind the session back to earlier and Pi summarizes what has happened on the other branch.

This all matters because for instance if you consider how MCP works, on most model providers, tools for MCP, like any tool for the LLM, need to be loaded into the system context or the tool section thereof on session start. That makes it very hard to impossible to fully reload what tools can do without trashing the complete cache or confusing the AI about how prior invocations work differently.

Tools Outside The Context

An extension in Pi can register a tool to be available to the LLM to call and every once in a while I find this useful. For instance, despite my criticism of how Beads is implemented, I do think that giving an agent access to a to-do list is a very useful thing. And I do use an agent-specific issue tracker that works locally that I had my agent build itself. And because I wanted the agent to also manage to-dos, in this particular case I decided to give it a tool rather than a CLI. It felt appropriate for the scope of the problem and it is currently the only additional tool that I’m loading into my context.

But for the most part all of what I’m adding to my agent are either skills or TUI extensions to make working with the agent more enjoyable for me. Beyond slash commands, Pi extensions can render custom TUI components directly in the terminal: spinners, progress bars, interactive file pickers, data tables, preview panes. The TUI is flexible enough that Mario proved you can run Doom in it. Not practical, but if you can run Doom, you can certainly build a useful dashboard or debugging interface.

I want to highlight some of my extensions to give you an idea of what’s possible. While you can use them unmodified, the whole idea really is that you point your agent to one and remix it to your heart’s content.

/answer

I don’t use plan mode. I encourage the agent to ask questions and there’s a productive back and forth. But I don’t like structured question dialogs that happen if you give the agent a question tool. I prefer the agent’s natural prose with explanations and diagrams interspersed.

The problem: answering questions inline gets messy. So /answer reads the agent’s last response, extracts all the questions, and reformats them into a nice input box.

/todos

Even though I criticize Beads for its implementation, giving an agent a to-do list is genuinely useful. The /todos command brings up all items stored in .pi/todos as markdown files. Both the agent and I can manipulate them, and sessions can claim tasks to mark them as in progress.

/review

As more code is written by agents, it makes little sense to throw unfinished work at humans before an agent has reviewed it first. Because Pi sessions are trees, I can branch into a fresh review context, get findings, then bring fixes back to the main session.

The UI is modeled after Codex which provides easy to review commits, diffs, uncommitted changes, or remote PRs. The prompt pays attention to things I care about so I get the call-outs I want (eg: I ask it to call out newly added dependencies.)

/control

An extension I experiment with but don’t actively use. It lets one Pi agent send prompts to another. It is a simple multi-agent system without complex orchestration which is useful for experimentation.

/files

Lists all files changed or referenced in the session. You can reveal them in Finder, diff in VS Code, quick-look them, or reference them in your prompt. shift+ctrl+r quick-looks the most recently mentioned file which is handy when the agent produces a PDF.

Others have built extensions too: Nico’s subagent extension and interactive-shell which lets Pi autonomously run interactive CLIs in an observable TUI overlay.

Software Building Software

These are all just ideas of what you can do with your agent. The point of it mostly is that none of this was written by me, it was created by the agent to my specifications. I told Pi to make an extension and it did. There is no MCP, there are no community skills, nothing. Don’t get me wrong, I use tons of skills. But they are hand-crafted by my clanker and not downloaded from anywhere. For instance I fully replaced all my CLIs or MCPs for browser automation with a skill that just uses CDP. Not because the alternatives don’t work, or are bad, but because this is just easy and natural. The agent maintains its own functionality.

My agent has quite a few skills and crucially I throw skills away if I don’t need them. I for instance gave it a skill to read Pi sessions that other engineers shared, which helps with code review. Or I have a skill to help the agent craft the commit messages and commit behavior I want, and how to update changelogs. These were originally slash commands, but I’m currently migrating them to skills to see if this works equally well. I also have a skill that hopefully helps Pi use uv rather than pip, but I also added a custom extension to intercept calls to pip and python to redirect them to uv instead.

Part of the fascination that working with a minimal agent like Pi gave me is that it makes you live that idea of using software that builds more software. That taken to the extreme is when you remove the UI and output and connect it to your chat. That’s what OpenClaw does and given its tremendous growth, I really feel more and more that this is going to become our future in one way or another.