Garry Tan Spends Up to $200,000 a Year on Tokens for AI Agents

Garry Tan has turned AI agents from a curious tool into a separate line item in his budget: the head of Y Combinator spends $100,000 to $200,000 a year on tokens. For that money he gets more than a chat for answering questions. Agents help him write code, research topics, prepare for interviews and work with a huge personal archive, from email and Dropbox to Apple Notes.

For a developer, the amount itself is not what matters. It shows where an agent's real value comes from: access to context, tools, and the ability to go through several steps without constant prompts from a human. But the same example immediately exposes three limitations: cost, data security and control over actions.

How an agent differs from an ordinary chatbot

Imagine an executive preparing for a meeting with a partner. An ordinary chatbot will receive one document, write a short summary and stop. An agent can find past correspondence, pull up notes from earlier meetings, check recent agreements, prepare a list of questions and point out contradictions in advance. The human sets the goal, and the system assembles the working chain itself.

This is how Tan describes his assistants: they don't just respond to a request, they suggest the next step. For this, an agent needs three things: memory about the user or company, access to suitable sources and a set of permitted actions. Without them, we are looking at the same chat, just with a longer system prompt.

At Y Combinator this approach has been carried over to the organizational level. According to Tan, the internal agent Stray Light has shared context about funded founders, applications and incoming correspondence. Such a "company brain" can potentially cut the time spent searching for information and let employees reconstruct the history of decisions faster.

The price of deep context

This setup has an unpleasant side. Tan's personal agent has read his email, files, notes and even therapy records spanning twenty years. The more the system knows, the more useful its answers are, and the heavier the consequences of a leak, an erroneous action or overly broad access.

That is why Tan's example cannot be copied literally. A developer should start with a narrow process: for instance, an agent analyzes build errors, finds related changes and proposes a fix, but is not allowed to roll it out to production on its own. A product team benefits from separating reading, preparing decisions and irreversible actions in advance. At each transition, the owner, the operation log and the point of human confirmation should be clear.

Cost also requires separate accounting. Tan's annual budget is out of reach for most teams, and the number of tokens spent says nothing about usefulness on its own. What needs to be counted is the cost of a completed task: how much the model, search, retries and human review cost; how much time or money was saved; and how often the result had to be redone.

What a team should do now

Choose one repeatable and sufficiently expensive process where the information is already stored in sources the system can access. Limit the set of data and actions, add logging, a spending cap and mandatory confirmation of critical operations. Then compare the agent with the current way of working on time, cost and share of successful tasks.

Tan's experience does not prove that every company needs a $200,000-a-year agent. It shows something else: a strong agent is built around context and actions, not around an impressive conversation. The practical gain starts where the system completes useful work. The practical risk is in the same place, because to do that it has to be trusted with data, permissions and budget.