Theo on Asking Agents for Outcomes and Building the Tools They Need

The hype around prompt engineering suggested we would all need to become experts at carefully engineered instructions. I think many engineers have the opposite problem: we over-engineer prompts and miss the chance to rethink what the computer can do for us. We do not ask our agents to do enough.

I am still learning this myself. Conversations with engineers have shown me how often people have not yet had the realization that their agent can do more than the narrow task they assigned it. I want to help you step outside the engineering box and consider what you want in work and daily life.

An old xkcd comic captures the gap between a user's request and an engineer's sense of difficulty: checking whether a photo was taken in a national park looked straightforward, while identifying a bird once seemed like a research project. Vision models have changed the latter. Today engineers face a different problem: we are so used to thinking in code that we overlook things we can simply ask an agent to investigate.

A friend wanted a T3 Code feature that would break down tool-call duration so he could identify slow commands. I had recently audited my own agent history and found that Claude's ripgrep calls often failed because commands written for Bash did not work in my Zsh environments. The information my friend wanted was already available to an agent.

I opened a new thread and asked for a breakdown of tool calls on the machine. The resulting report showed, among other things, a home-directory search lasting 41.7 minutes and another lasting roughly nine minutes. It suggested searching the repository or a known directory instead. The report provided useful information without a dedicated product feature for that specific question.

We are accustomed to needing a feature in a tool to get information from it. But if the relevant data is accessible, an agent can often answer an ad hoc question. That does not mean every feature should disappear; it means information requests can sometimes be handled without building a dedicated interface first.

I had been designing a dashboard for all my active T3 Code work: statuses, recommendations, buttons for renaming threads and ways to act on PRs. As I kept adding controls, I realized another option was a meta thread connected to my environments, where I could ask for the particular view or analysis I wanted.

I also asked for a visualization of a thread's context window. A similar exercise had revealed that my proxy configuration was adding around 70,000 tokens to each request. These reports take time to generate, but if a task can run in the background, the delay need not stop me from doing other work.

The important shift is to ask for useful one-off outcomes that would never have justified a permanent feature. I have made visualizations to understand a single bug and combined music history from different services. These were tasks I might otherwise have left undone, not necessarily products I needed to maintain.

Someone asked for a way to choose the model used by delegated agents. In my setup, the model already selects delegates, so I can describe what I want in the prompt. I demonstrate asking one agent to start two Opus delegates for performance exploration and then open a separate implementation thread with another model.

The request controls the delegate choice without a new dropdown in this example. When I find myself repeating the same instruction, that is when I consider updating a skill or an agent instruction file. The generated context-window report is also something I could refine by asking, then turn into a reusable skill if it proves valuable.

This mindset also changes what I build. A user had serious T3 Code problems on Windows, and I found myself writing prompts for them to run in an agent on their own machine. That inspired T3 triage, a command-line flow that can work even if the desktop app will not open.

Instead of building an elaborate application that asks each question through custom code, the command gathers basic machine facts, lets the user choose an agent harness, and passes it a playbook. The agent acts as a support engineer: understand the problem, help unblock the user and prepare a useful issue when appropriate.

The playbook starts by asking what went wrong in the user's own words, requesting screenshots if available and following up on vague descriptions. Good reproduction steps are especially valuable. It then reads machine facts, checks for an updated playbook and can inspect the open-source code.

The agent investigates and checks upstream for an existing fix. If an issue is warranted, it should remove secrets and other sensitive data before filing, and prefer contributing to an existing issue over creating a duplicate. I originally expected this feature to require thousands of lines; the version I describe uses a small command and a Markdown playbook.

I had spent time trying to handle pasted images in a custom triage interface before realizing the chosen agent could ask the user for a screenshot. A dynamic troubleshooting flow has many branches I cannot anticipate. If I knew every failure in advance, I could have fixed them instead of building triage.

So what remains to be engineered? One answer is access to better evidence. I had a rendering flicker in T3 Code and suspected we did not log enough to investigate it afterward. I asked the agent whether historical rendering data was available and what we could expose to make future debugging more useful.

I also asked a desktop agent to describe its available computer-use capabilities. It described discovering and operating apps, reading interfaces, using screenshots and accessibility information, interacting with mouse and keyboard, and verifying results. I used that description as input for work on similar capabilities in T3 Code.

You can ask an agent why it did not attach a screenshot to a PR, what tool it would need, why an investigation stalled, or whether it can inspect another thread. You can prompt about your prompts, tools, programs and systems—not just ask for a code change. The answer still depends on the data and access the agent actually has.

I have even used an agent to help collect medical files from portals for my doctors. I could have built a program for that, but asking for the one-time task was more useful to me. The point is not that a prompt replaces every program; it makes some work feasible that I would never have built a dedicated tool to do.

Once I see which requests are useful, I can focus engineering on the primitives they need: workflows, tools, pipelines, data access and connections between systems. Prompting and building reinforce each other when the agent can reach the information needed to fulfill the request.

A personal example was connecting several email inboxes to ChatGPT. After a hand injury made email harder to manage, I tried asking an agent about my messages and found that I checked inboxes less often. That is my experience with my own accounts and workflow, not a guarantee that every setup behaves the same way.

I can ask an agent to look for a particular bill and then investigate a cost increase in the relevant dashboard. In my setup I connected T3 Code through MCP, so work can continue in other agent threads. The useful part is the data and tooling connection: the prompt can reach across systems rather than ending at an inbox.

At times this shift made me feel less like an engineer because I was no longer focused on every framework or line of code. Then I realized that giving agents reliable systems to operate within creates new engineering problems. Building a triage flow, exposing an application over MCP or providing useful data are all engineering work.

I have been experimenting with Rust applications and infrastructure for cheaper agent compute. Problems that were once too expensive to tackle, or not useful to enough people, can become worthwhile when agents make them easier to build and more people can use them. That is where I find much of the excitement now.

I often see T3 Code feature requests that could begin as a question to an agent rather than a product-specific button. But this approach still needs good primitives. For example, an agent can generate an HTML visualizer today; an inline visualizer would provide a way for users to see a dynamically generated view inside the product.

For engineers who feel that AI has taken away the parts of work they loved, I understand the discomfort. My own experience included a dip in confidence as familiar work changed. I think the new opportunities can appear once you look at what needs to be built around the agent rather than only at the code it writes.

I used to spend more time assembling user-facing solutions; now I am exploring operating systems, compilers and connection layers because those problems have become both more relevant and more practical for my work. I do not inspect every SQL query, but I may think deeply about the connection between the database and server.

That is my experience, not a promise that everyone will feel the same transition. The invitation is to ask more broadly, examine what the agent lacks, and build the systems that make useful requests possible. There is still plenty to engineer—and plenty of room to make something new.