You can reach me by railway
You can reach me by trailway
You can reach me on an airplane
[…] I don’t care how you get here
Just get here if you can

Brenda Russell, Get Here

Don’t Even Ask Me What to Drive to the Grocery Store.

There has been a lot of talk in AI lately about not using a Ferrari to go to the grocery store. Which model should handle each task, and how much money are we wasting by reaching for the most capable one every time?

The point is reasonable. Classifying a support ticket or extracting line items from an invoice probably does not need the most expensive frontier model available. Do not burn Ferrari money on scooter work. Save the powerful model for the hard problem.

But I think we are still asking the wrong person to solve it.

I do not want to choose the car. Most of the time, I should not even need to know which grocery store the agent chose.

I want to tell my agent that I need a tomato. Or a salad. Or that I am having ten people over for dinner on Saturday and I need the whole thing handled.

The agent can decide whether that means using a cheap model for a simple task, asking a frontier model to reason through something difficult, spinning up a few independent researchers, or calling DoorDash. I care that the food is good, it arrives on time, nobody has an allergy problem, and I did not have to become the logistics coordinator for a dinner party.

Choosing The Model Should Not Be My Job

Software has been climbing abstraction layers for a long time. Most developers do not decide which CPU register should hold each value or which assembly instructions should execute a function. Those choices did not disappear. They moved to the compiler and runtime, which have a better view of the lower-level problem than the person trying to build the product.

Model selection feels similar. Cost, latency, context limits, and reliability all matter. But asking the user to choose a model for every task feels a little like asking an application developer to choose the assembly instructions for every function. It may occasionally be necessary, but it should not be the normal interface.

I want one capable agent at the front door. I want to tell it what I need, what constraints matter, and maybe what I am willing to spend. Then I want it to decide how to allocate the work.

Maybe it handles the request itself. Maybe it gives the mechanical work to a cheaper model. Maybe it sends several agents into a codebase and asks them to come back with different answers. Maybe it spends more time reasoning because a decision is hard to reverse, or asks me a question because the request is genuinely underspecified.

Fable 5 and GPT-5.6 Sol have made this feel less theoretical to me. I can give them a broad project, let them delegate pieces of it, hit roadblocks, try something else, and keep working while I am away.

Talk To Alfred

The product I want is Alfred.

I want to tell him what needs to happen and let him figure out how to make it happen. I do not want to call vendors, compare services, choose models, or decide which part of the work belongs to whom.

I should be able to say, “I need this bug fixed,” “I need a good first draft of this post,” or “I need to be ready for this meeting tomorrow.”

Alfred does not come back and ask whether I would prefer he take the Ferrari or the motorcycle to the market. He understands the dinner, the timing, the constraints, and presumably my tolerance for spending money on truffles. Maybe he makes the trip himself. Maybe he hires someone or calls a service. I do not need to make that choice for him.

I am not alone in wanting model choice to move down a layer. Ramp has just opened up Ramp Router, the system it built for more than 100 internal AI use cases. Ramp says it cut its LLM costs by about 30 percent by sending each request to the lowest-cost model that clears its quality bar. OpenRouter, Not Diamond, and the open-source RouteLLM are working on versions of the same problem.

They are solving a narrower version of the problem – routing one request rather than owning the whole outcome – but the direction is the same. Model selection is starting to become part of the infrastructure underneath the work.

For Now, I Still Choose

Today, I am still conscious of AI spend and model choice. I think about whether a task needs Haiku, Opus, Fable, Sol, or something else. Sometimes I deliberately choose the cheaper model. Sometimes I pay for the most capable one because the work is difficult or I do not want to babysit it.

Long term, I want most of those decisions to fade into the background. I want to give the agent the outcome, the constraints, and the budget, then let it decide when a cheaper model is enough and when the work justifies spending more.

I still want to reach for the controls in an edge case. I should be able to pin a model, cap the spend, or tell the agent to optimize for quality over cost. I just do not want model selection to be a question I have to answer before most work can begin.

For now, I still choose between the Ferrari and the scooter. Long term, I want that choice available without having to make it every time. Most of the time, I just want the tomato to show up. Whether the agent took the Ferrari, rode the scooter, or called DoorDash can stay in the background.

“You want it to be one way. But it’s the other way.”

Marlo Stanfield, The Wire

On a trip with my parents, we had a car for the day and a rough list of places we wanted to see.

Just before we left, an auntie came over and told me how nice it was to see me again. Then she smiled and said, “It’ll be fun. Let’s go outside and join your mom in the car.”

I took that to mean she was joining our trip at the last minute. I was surprised, but I did not mind.

Except every stop seemed to need her approval.

My mom would suggest somewhere, auntie would say it was too far or that another stop made more sense first, and the plan would change. It was never a big argument. The day just kept getting rearranged around what worked for her.

At a couple of stops, auntie did not even come inside with us. She stayed in the car until we were ready to go again.

My mom is always incredibly kind to our friends and family, so at first I assumed she was simply being a generous host. But after the plan changed a few times, it started to seem like we were deferring a bit too much to someone who, as far as I understood it, was just tagging along for the day.

After this happened a few times, I finally asked my mom why we were checking with auntie about every stop. I thought she was coming with us for the day.

My mom looked at me. “Sid, this is her car.”

My parents had planned to hire a car for the day, but that fell through. Auntie was already planning to go into the city, so she told them she would not mind if we joined her. She was taking us along, adjusting her route, and waiting while we made our stops.

I Had The Roles Backwards

What confused me was not the itinerary itself. It was how someone I thought was a guest had somehow become the decision-maker.

In my version of the day, my family had the plan and auntie was joining us. Of course she could have preferences. But every time my mom deferred to her, it felt like someone along for the ride had suddenly taken control of it.

Once I understood what was happening, my mom’s behavior made sense. Auntie was spending the day taking us around. Of course we were going to check what worked for her.

I Have Seen This At Work Too

The same role mismatch shows up at work. Two people can leave the same meeting each believing they own the decision, then give the team conflicting direction. Or everyone can agree on the general direction and still leave without knowing who is responsible for driving the next steps. That ambiguity can turn an ordinary disagreement into a conflict over authority, or leave a decision sitting still after an otherwise useful meeting.

DACI gives those different responsibilities names. The Driver owns the work required to get the decision made: coordinating stakeholders, gathering the necessary information, addressing open questions, and keeping the process on schedule. The Approver is the one person who makes the final call. Contributors provide expertise and recommendations, while the people who are Informed need to know the outcome because it affects their work.

When those roles are unclear, the team is working on two problems at once: the problem itself and an alignment problem about who is responsible for what. More context may improve the discussion, but it will not tell anyone who should move the decision forward or make the final call.

Once the roles are clear, the conversation gets simpler. Everyone knows whether the decision is still open, what input is needed, who will make the final call, and when. People can disagree without being confused about their role in the decision.

That was the missing piece on our day trip. Everyone except me understood the arrangement. One sentence at the start would have changed how I read every conversation: “The person we planned to hire fell through, so auntie is doing us a favor letting us join her while she goes into the city today.”

With that context, I still would have had opinions about where we should go. But I would have known I was the passenger – and been grateful that auntie was letting us tag along.

“Mr. Watson—come here—I want to see you.”

Alexander Graham Bell, 1876

I was talking with a friend who also spends a lot of time working with AI agents. We started comparing our setups: the instructions we had accumulated, the prompts we reused, and the small decisions that had made our workflows work better over time.

It was a fun conversation, but we both had far more context than we were going to reconstruct from memory while we talked.

Later, I went home and sat down at my desk. I was still thinking about the conversation when I had an idea.

My working model lives in an Obsidian folder. It is not one polished process document. It is a collection of files, notes, instructions, examples, and smaller sub-workflows that have accumulated as I have worked with my agents.

What if I had my agent package the whole thing into one markdown file that I could send him?

I asked it to bring the material together without sanding off all the detail. The file covered how I turn a vague idea into a project, how I use Technical Design Docs, what makes a ticket title useful, what belongs in a ticket description, when I use milestones, how much context feels like enough, and when planning should finally turn into coding.

I thought of it as a one-pager in the sense that it was now all on one page, not in the sense that it was short.

I was excited about the idea, so I sent it to him.

“Don’t read this. Give it to your agent.”

Then He One-Upped Me

He was amused, and I think he was as excited by the idea as I was. But he did not simply hand the file to his agent and forward me whatever summary came out.

He had his agent analyze my workflow against his own. Then he read the analysis, talked through it with his agent, added his own reactions and context, and sent me back the combined thoughts from both of them.

I thought I had done the clever thing by packaging my workflow for his agent. He turned it into a conversation with his agent and sent back something better.

Have your agent call my agent.

It is a ridiculous sentence, but look at what had just happened. My agent packaged my workflow, his agent picked it apart, and my friend sent back the combination of what his agent noticed and what he thought about it. Honestly, that was much more useful than the two of us trying to explain every file and sub-workflow over a call.

A Diff Between Two Ways Of Working

What came back was more useful than a summary of my files. It showed where our approaches were similar, where mine was more explicit, what he was doing that I was not, and which ideas might be useful to borrow without declaring one process better.

It was almost like getting a diff between two ways of working.

Personal workflows are not code, of course. An agent can misunderstand why a preference exists, make a small difference sound important, or recommend something that does not fit the person receiving it. Neither of us wanted to adopt the other person’s process wholesale.

But neither of us had to read a giant folder cold and somehow know what mattered. We could get closer to the questions we actually wanted to discuss: Why do you structure projects that way? When does a design document help, and when is it just overhead? What information lets an agent keep working without stopping to ask another question?

I sent my friend a file because I was excited about my idea. He sent back a better version of the experiment. I am still deciding what to steal.

“The output of a manager is the output of the organizational units under his or her supervision or influence.”

The main idea of High Output Management: management is output, leverage, and systems that help people do better work.

Interesting Ideas

• Meetings are a manager’s medium of work, not an interruption from work.
• Leverage matters more than busyness.
• Activity and output are easy to confuse, especially in knowledge work. You can answer messages, attend meetings, and generate updates without meaningfully changing what the team produces.
• Delegation does not erase responsibility. A manager still owns context, clarity, checkpoints, and follow-through.

“Delegation without follow-through is abdication.”

• Task-relevant maturity is more useful than generic seniority. Someone can be independent in one area and need close support in another.
• Performance problems usually come down to capability, motivation, or clarity. Before blaming attitude, ask whether the person knows what good looks like, can do the work, and has a reason to care.
• Planning is only useful if it changes what you do now. The point is not to predict the future perfectly; it is to decide which current actions make tomorrow less chaotic.
• Culture is transmitted by visible behavior. People learn the real rules by watching what gets rewarded, ignored, tolerated, escalated, and repeated.

Quotes

• “When a person is not doing his job, there can only be two reasons for it. The person either can’t do it or won’t do it; he is either not capable or not motivated. To determine which, we can employ a simple mental test: if the person’s life depended on doing the work, could he do it? If the answer is yes, that person is not motivated; if the answer is no, he is not capable.”
• “The single most important task of a manager is to elicit peak performance from his subordinates. So if two things limit high output, a manager has two ways to tackle the issue: through training and motivation.”
• “Remember that by saying ‘yes’ to projects, a course of action, or whatever – you are implicitly saying ‘no’ to something else.”
• “The art of management lies in the capacity to select from the many activities of seemingly comparable significance the one or two or three that provide leverage well beyond the others and concentrate on them.”
• “To make things work, people do not need to side with you; you only need them to commit themselves to pursue a course of action that has been decided upon.”

Related Reflections

• Delegating Doesn’t Mean Disappearing
• Growing Your Team With Stretch Assignments
• Why You Want The Hard Questions
• AI Agents and the Work You Shouldn’t Be Doing

“Time is what we want most, but what we use worst.”

William Penn

Agentic coding is enabling people to take on tasks they otherwise lack the skillsfor:  product managers can ship  small code changes, server-side engineers can contribute to front-end design and stories abound of folks prototyping ideas to show a live demo of their vision.

But AI agents can also do work you are perfectly capable of doing, that you probably should not be spending your best attention on.  In some cases, mechanical tasks like refactors and summarization are much faster with agents, while other times, they may take on tedious work and do it more slowly and tediously.  It’s these latter tasks I’ve been especially excited about experimenting with lately.

The Consultant Math

Years ago, when I was working at a Fortune 500 company, my boss brought in a consultant who was supposed to be one of the best in the technology we were using, and I was really excited. We had tons of work to do, and getting a partner, potentially someone much more experienced than me, was going to help us speed things up a ton – or so I thought.

Within a few weeks, I  was frustrated.  The consultant was competent, but he was taking days to do things I felt like I could do in hours. Why were we paying for this person who felt like they were only a quarter as effective as I was? From my point of view, the math did not make sense.

I talked to my boss about it, and he gave me a different way to look at it. On any team, he told me, you are going to have A players, B players, and C players – and as one of his A players, he needed to do whatever it took to maximize my contributions on the team, including freeing me up from lower level tasks – regardless of how long the “replacement” person took.

From his perspective, part of a manager’s job is to figure out how to use the people they actually have.  By hiring a consultant, every hour of my time not spent working on tasks that I hadn’t off was an hour I could spend on work more valuable to him and the company.

It did not matter if the consultant was slower than me. If that consultant worked all week and gave my boss another day of my time, that was worth it.

Analogous With AI Agents

In some cases, I’ve experienced this same thing with AI agents – especially when they need to read through my knowledgebase to gain context on a simple request.

For example, putting together an agenda and collating what action tickets are done, what are outstanding and what items do we need to discuss requires a lot of context that I have in my head: the relevant meeting history, discussions that occurred in Slack, comments that have been added to various documents, and sometimes messages in my DMs.

Having the context is already loaded into my head means I can type up a summary from scratch in lets suppose fifteen to twenty minutes.

Meanwhile, to provide this same context, Claude or Codex or pick your agentic tool, needs to read the knowledge base, search through notes, search through slack messages, review the meeting agenda and transcript and then put the notes together.  In these kinds of tasks, even as computers can process individual pieces of information much faster than humans, I’ve found it can take 2-3x as long churning away to spit out a first draft.

So, in a race, I win.  But it’s not a race: it’s about leverage.  If I spend a couple minutes giving direction (or even better, having a recurring event that checks my calendar for a meeting, and automatically goes off a pre-made skill every time it hits a match…), go to a meeting, and come back to something useful, it makes no difference to me if the agent took a minute or an hour. All that matters is I have the output I need before the end of the day, so I can spend a couple minutes reviewing or tweaking and send it out.

Leveling Up vs. Leveling Down

A lot of the experimentation I’ve seen around AI is about leveling up. People can do things that previously sat outside their role or skill set, and that changes what small teams can build.

But I am increasingly interested in the reverse pattern: using AI to avoid leveling down.  Building repeatable, often scheduled/automated processes to churn through repetitive tasks to free up minutes and mental focus.

For now, it’s a 80-90% solution: I still decide what matters, review the output, and make small change.

Some tasks are a bad fit: subtle judgment, sensitive communication, high-stakes decisions, or context too messy to hand off cleanly. Those can create more review work than they save.

Repetitive, slightly annoying tasks are excellent candidates.  I’ve personally set up automations to:

• Triage my email every hour.
  • It “automatically” provides me context on the emails, and based on information in my personal knowledge base, drafts responses as needed.  I review the drafts before anything is sent out.
• Bubble up “Top of Mind Items.”
  • Prepare a start, middle and end of day VIP list of tasks to work on based on the full context from emails, my calendar, direct messages and tags, items I’ve personally saved for later and tickler files of sporadic events.
• Create Repeating Documents.
  • Automatically create the next meeting agenda with placeholders in our content management system.  I have a weekly status update I write, and it drafts it for me based on the prior draft, and what it knows my team has done.
• Find and Update Actions Items:
  • Parse all previous meeting notes and find action items for me, putting them in a single document I interact with and linked back to the source. When I check items off or comment on them, it automatically propagates my notes back so I don’t have to interact with the other documents.

Unsurprisingly, this list likely looks a lot like what a dream executive assistant might do. In a world where this context is increasingly accessible to agents, they’re able to take on more and more of it, to free up my time to spend on larger problems and working with my team and cross functional partners.