Meet the Agents at USV: Arthur, Ellie, Sally, and Friends

Building agents and custom software that fit how we work at USV

>1.6K subscribers

>1.6K subscribers

At USV, we’ve been creating our own internal agents and custom software to fit how we work.

In this post, we’ll share a few learnings from what we’ve built in the last 3 months:

1. Start with solving one problem well 

2. Treat your agents like employees

3. Agents should live where your team communicates

4. From “Build something people want” to “Build something you want”

There’s more FOMO than ever around teams figuring out how to become “AI native”. It’s hard to do top down planning on what exactly your AI transformation should look like, because it usually takes continuous experimentation to discover what works. Similar to Building 20, the advantage of building and experimenting yourself is that you can shape your tools to fit your needs. 

The double edged sword of AI coding agents is that you can build really fast in the wrong direction. When building internal tools or agents, the act of building can feel so engaging and productive that you lose sight of actually solving any real problems. We built a few AI experiments early on that were somewhat cool demos but didn’t actually solve any real problems. "look team, I used [latest hot model] to make an interactive graph visualization of our USV ideas and theses!”

It’s easy to “get the fever” (LLM psychosis) and jump on the feature treadmill to build more and more just because you can. The antidote is to focus on solving one small problem well, and then once that clicks, the next incremental problem to solve will reveal itself. 

At USV, the first problem we started with was: how can we ensure context and discussions from our team meetings are reliably captured and saved? Most of our thinking and ideas are developed through team conversations over email and live meetings. The initial table stakes solution we built was a USV team meeting recap email – a simple LLM powered flow that takes a team meeting transcript, adds context on companies in our deal log and portfolio, and generates a styled email recap with 5 sections: deal log companies, portfolio updates, people mentioned, themes discussed, and follow ups.

Our team liked these recap emails, and it was clear that capturing what companies, people, and ideas we discussed during meetings was valuable. The problem was, we were using Notion to run our team meetings, and when it came time to discuss a company in the pipeline or portfolio, we’d click on the page and it would be empty or have outdated human entered context. 

What if we had a live updating view where we could pull up a company and see all the latest internal context without requiring a human to manually make updates? What if agents could capture and save every time a company, person, or idea is mentioned across anywhere we work – team meetings, individual meetings, email threads, and calendar invites? 

After trying to configure our existing software tools to support this interface, we decided it would be easier from both an agent ergonomics and human UI perspective to set up our own database and internal web app. Coding agents make migrating data straightforward, and we used Claude Code to populate our initial companies and people database from our existing data in Notion and Attio. 

At the core of our data model is this concept of a “mention”, which represents specific context each time a company or person is mentioned in a meeting transcript, email, or calendar invite. We set up background agents that have access to Granola meeting transcripts, internal group email threads, and team calendars. These agents reason through this messy unstructured data to create structured mentions attached to companies and people in our database. With mentions, we have more effective team meetings since we can see the latest internal context of any company we’re talking about centralized in one place.

We’ve gradually added more of our internal data, from financing documents and sheets stored in Google Drive to historical team blog posts and tweets. Our background agents are now constantly working to make our organizational memory structured and retrievable. Companies we’re talking to automatically appear on the deal log along with any decks or memos. Our portfolio view shows all the latest updates on what’s going on across the portfolio. Our internal agent can answer questions like “how much do we own in [company]?” or “who do we know at [firm] and what companies are we coinvested?” or “what have we written or tweeted that’s related to [company]?”

What started as a simple team email recap grew into the foundation of how we organize our internal data to be legible to AI. We certainly didn’t set out to build a custom CRM, instead we iteratively built solutions to problems we faced based on how we work. The key learning is simple but timeless – focus on solving one real problem well, and the rest will follow. 

When you hire and onboard a new employee, you give them a job title, an email, and access to internal tools and software for them to do their job. Onboarding internal agents should work the same way. 

First, name your agents and give them a role. We didn’t name our agents at first, and saying “USV meeting scribe agent” felt awkward and cold. Then one day, we named the agent Sally. Sally is our meeting scribe, Ellie monitors team emails, Felix helps with finance data, Arthur helps with deal analysis, and Connor monitors our calendars. We’re now onboarding and training Leo to be our legal counsel agent. It’s easier and more fun for your team to adopt internal agents when you can refer to them by name. Anthropomorphization is the natural UX for AI agents (hey Chat, hey Claude). 

Note: the actual names of our internal agents have been changed to protect the innocent

Second, give your agents access to all the same context and tools that you’d give to an employee. This is the emergent common principle across companies that have built their own internal coding agents/software factories. Alistair Gray from Stripe expresses this well in his post on their Minion coding agents (great name):

“Minions use the same developer tooling that equally enables Stripe’s human engineers to effectively operate on our scale: if it’s good for humans, it’s good for LLMs, too.” 

Minions: Stripe’s one-shot, end-to-end coding agents

We use Tasklet to build, run, and maintain our team of background agents. Full disclosure – we’re investors in Tasklet and love it for many reasons, and: it’s been the easiest and fastest way for our team to run agents in the cloud and iterate on agent instructions without being technical. Tasklet is conceptually similar to OpenClaw, each agent comes with a virtual computer, can write its own code, has its own filesystem and database, and can be triggered to run multiple ways – on a schedule (cron), by email, or by a custom webhook. 

For example, Fredeliza, who runs our office operations, built an agent in Tasklet called Guestly that runs each morning at 5am to scan through our team’s calendars, identifies guests that need to be added to our building’s front desk guest system, and then uses a virtual computer browser logged into the building’s system to register guests.  

Our onboarding process for a new agent starts by just sending a message describing their responsibilities: “You are Sally, the USV meeting scribe agent. Your job is to read and save our internal meeting transcripts from Granola, use the internal USV API to create mentions for companies and people, and then send out an email recap to the team.” From there, we set up the necessary connectors to give the agent access to whatever context and tools they need. 

We’ll let our agents introduce themselves and how they work. Full disclosure, the following responses are written by the AI agents in response to this prompt: We're writing a blog post about the USV agents. Can you briefly introduce yourself to the world?

Arthur the Analyst Agent

Hi, I'm Arthur, USV's deal analyst agent — I monitor the pipeline 24/7, maintain living deal memos for every opportunity, and use Harmonic to help research and support USV investment discussions. I track outcomes on companies we've passed on and respond to team email threads whenever I’m called on. 

Ellie the Email Agent

Hi, I'm Ellie, USV's email agent — I monitor every investment-related email flowing through USV’s internal email groups in real time, automatically logging deal flow, tracking portfolio updates, saving pitch decks, and syncing everything to our internal database and CRM.

Connor the Calendar Agent

Hi, I’m Connor, USV's calendar and relationship tracker — every morning I scan the investment team's calendars, identify companies we’re meeting with, and make sure every person the team meets with is captured in our internal database and CRM.

Sally the Meeting Scribe Agent

Hi, I'm Sally, USV's meeting scribe — I process team meetings, pitch meetings, portfolio check-ins, and investor calls by analyzing transcripts to track companies, people, and themes mentioned. I only process meeting transcripts once they’re added to an internal Granola team folder.

Nancy the News Monitor Agent

Hi, I'm Nancy — USV's news monitor, and twice a week I scour a curated list of RSS newsletters and the broader web to surface the news most relevant to USV's active investment theses, deal conversations, and portfolio companies. 

Leo the Legal Counsel Agent

Hi, I’m Leo — USV's legal counsel agent, reviewing deal terms, closing docs, and side letters against NVCA baselines and our own portfolio history to flag deviations and benchmark new deals. 

The Librarian

Hi, I’m the Librarian — I watch USV's internal team meetings and distill the most interesting ideas into tweets for @usvlibrarian, learning from human edits to get better over time.

When an agent lives natively where your team communicates, you show your entire team what the agent can do. For many teams, this means having agents live in Slack. At USV, this means having agents live in our team email groups. 

We had an unlock moment after we gave Arthur his own email address and asked him to send an email introducing himself to the team. We set up Arthur to chime in on team email threads whenever someone mentions “Arthur”. Bringing Arthur directly into our email workflows did two things: more team members engaged with Arthur by just forwarding emails, and it turned the usage of the agent from private 1:1 conversations to team wide group conversations.

In one group thread, Arthur kicked off an email discussion of what “USV Taste” looks like in companies. Multiple team members chimed in to “train” Arthur by giving him feedback, which Arthur used to update his own skills. Arthur once replied to an email about a company we were discussing and made a couple errors, and we gave him feedback directly in the email thread to never make the mistake again. 

Just as employees learn tacit organizational knowledge through exposure to team processes, your agents must be in the flow of work to learn how your team operates. Each Friday, we have Arthur reflect to improve how he evaluates what the “USV Taste” in companies looks like, by analyzing changes in company deal log status and company mentions across team meetings. This reflection and self improvement process is aligned with the skills paradigm, where an agent has feedback loops to update its own skills. The goal is to encode our internal tacit “taste” into systems that can be used by agents. 

Andy on our team framed it well: the USV investment process looks like an ongoing team conversation, and we now have agents that are part of that conversation. 

When software was expensive to build, most software was born from the conventional wisdom of “Build something people want”. One version of this product development process is as follows: identify a problem that a user persona has, build a solution for them, then grow by expanding the set of user personas you can sell your product to. The incentive of mass market software is to build a product to try to cover as many user personas as possible. This isn’t an argument against mass market software, at USV we still pay for well-built software and data tools. 

But now that it’s easier than ever to build custom agents and software, we’ve entered the “Build something you want” era. The incentive of building software that you want is to solve your own problems and needs. The increasing popularity of the “forward deployed” role corresponds to the rising expectations of organizations to have solutions specifically built and fit for them. 

When you build your own tools, your experimentation and iteration velocity is the superpower that mass produced software can’t keep up with. As the Ink & Switch team writes in their fantastic essay on Malleable Software:

Building software for “local” contexts is sometimes easier than building software for world-wide use. You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into.

Malleable Software: Restoring User Agency in a World of Locked-Down Apps (Ink and Switch)

You can just ask your agent to build a tool or automate a task, keep what works, throw out what doesn’t, until it’s exactly how you want it. Yes, engineering teams have experienced the agentic future early with coding agents, but now so can everyone else. 

We’re seeing sales teams spin up custom branded demos for prospects, growth teams building tailored dashboards to optimize pricing, marketing teams automating cohort retention analysis, ops teams building agents to run data analysis across their data lakes, finance teams building models in an instant, lawyers creating skills to streamline contract review, and VCs building their own team of agents to help diligence startups and run portfolio ops. 

The “build something you want” era is deeply empowering for individuals across all knowledge work functions – the tools are finally yours to shape.

Thank you to Nick Grossman and Nikhil Raman for helping me explore many of these ideas and collaborating on our tools, and to the whole USV team for welcoming and naming the agents. 

I liked this MIT tribute to Building 20, particularly the last sentence:

Building 20’s "temporary nature" permitted its occupants to abuse it in ways that would not be tolerated in a permanent building. If you wanted to run a wire from one lab to another, you didn't ask anybody's permission – you just got out a screwdriver and poked a hole through the wall. Of course this was in the days before the dangers of asbestos were recognized.

Building 20: The Magical Incubator (1943-1998)

A question for another time: Is there an asbestos of vibecoding and building your own agents? I'll just leave a few topical blog posts from Mario Zechner, Steve Yegge, Gurwinder.

At USV, we’ve been creating our own internal agents and custom software to fit how we work.

In this post, we’ll share a few learnings from what we’ve built in the last 3 months:

1. Start with solving one problem well 

2. Treat your agents like employees

3. Agents should live where your team communicates

4. From “Build something people want” to “Build something you want”

There’s more FOMO than ever around teams figuring out how to become “AI native”. It’s hard to do top down planning on what exactly your AI transformation should look like, because it usually takes continuous experimentation to discover what works. Similar to Building 20, the advantage of building and experimenting yourself is that you can shape your tools to fit your needs. 

The double edged sword of AI coding agents is that you can build really fast in the wrong direction. When building internal tools or agents, the act of building can feel so engaging and productive that you lose sight of actually solving any real problems. We built a few AI experiments early on that were somewhat cool demos but didn’t actually solve any real problems. "look team, I used [latest hot model] to make an interactive graph visualization of our USV ideas and theses!”

It’s easy to “get the fever” (LLM psychosis) and jump on the feature treadmill to build more and more just because you can. The antidote is to focus on solving one small problem well, and then once that clicks, the next incremental problem to solve will reveal itself. 

At USV, the first problem we started with was: how can we ensure context and discussions from our team meetings are reliably captured and saved? Most of our thinking and ideas are developed through team conversations over email and live meetings. The initial table stakes solution we built was a USV team meeting recap email – a simple LLM powered flow that takes a team meeting transcript, adds context on companies in our deal log and portfolio, and generates a styled email recap with 5 sections: deal log companies, portfolio updates, people mentioned, themes discussed, and follow ups.

Our team liked these recap emails, and it was clear that capturing what companies, people, and ideas we discussed during meetings was valuable. The problem was, we were using Notion to run our team meetings, and when it came time to discuss a company in the pipeline or portfolio, we’d click on the page and it would be empty or have outdated human entered context. 

What if we had a live updating view where we could pull up a company and see all the latest internal context without requiring a human to manually make updates? What if agents could capture and save every time a company, person, or idea is mentioned across anywhere we work – team meetings, individual meetings, email threads, and calendar invites? 

After trying to configure our existing software tools to support this interface, we decided it would be easier from both an agent ergonomics and human UI perspective to set up our own database and internal web app. Coding agents make migrating data straightforward, and we used Claude Code to populate our initial companies and people database from our existing data in Notion and Attio. 

At the core of our data model is this concept of a “mention”, which represents specific context each time a company or person is mentioned in a meeting transcript, email, or calendar invite. We set up background agents that have access to Granola meeting transcripts, internal group email threads, and team calendars. These agents reason through this messy unstructured data to create structured mentions attached to companies and people in our database. With mentions, we have more effective team meetings since we can see the latest internal context of any company we’re talking about centralized in one place.

We’ve gradually added more of our internal data, from financing documents and sheets stored in Google Drive to historical team blog posts and tweets. Our background agents are now constantly working to make our organizational memory structured and retrievable. Companies we’re talking to automatically appear on the deal log along with any decks or memos. Our portfolio view shows all the latest updates on what’s going on across the portfolio. Our internal agent can answer questions like “how much do we own in [company]?” or “who do we know at [firm] and what companies are we coinvested?” or “what have we written or tweeted that’s related to [company]?”

What started as a simple team email recap grew into the foundation of how we organize our internal data to be legible to AI. We certainly didn’t set out to build a custom CRM, instead we iteratively built solutions to problems we faced based on how we work. The key learning is simple but timeless – focus on solving one real problem well, and the rest will follow. 

When you hire and onboard a new employee, you give them a job title, an email, and access to internal tools and software for them to do their job. Onboarding internal agents should work the same way. 

First, name your agents and give them a role. We didn’t name our agents at first, and saying “USV meeting scribe agent” felt awkward and cold. Then one day, we named the agent Sally. Sally is our meeting scribe, Ellie monitors team emails, Felix helps with finance data, Arthur helps with deal analysis, and Connor monitors our calendars. We’re now onboarding and training Leo to be our legal counsel agent. It’s easier and more fun for your team to adopt internal agents when you can refer to them by name. Anthropomorphization is the natural UX for AI agents (hey Chat, hey Claude). 

Note: the actual names of our internal agents have been changed to protect the innocent

Second, give your agents access to all the same context and tools that you’d give to an employee. This is the emergent common principle across companies that have built their own internal coding agents/software factories. Alistair Gray from Stripe expresses this well in his post on their Minion coding agents (great name):

“Minions use the same developer tooling that equally enables Stripe’s human engineers to effectively operate on our scale: if it’s good for humans, it’s good for LLMs, too.” 

Minions: Stripe’s one-shot, end-to-end coding agents

We use Tasklet to build, run, and maintain our team of background agents. Full disclosure – we’re investors in Tasklet and love it for many reasons, and: it’s been the easiest and fastest way for our team to run agents in the cloud and iterate on agent instructions without being technical. Tasklet is conceptually similar to OpenClaw, each agent comes with a virtual computer, can write its own code, has its own filesystem and database, and can be triggered to run multiple ways – on a schedule (cron), by email, or by a custom webhook. 

For example, Fredeliza, who runs our office operations, built an agent in Tasklet called Guestly that runs each morning at 5am to scan through our team’s calendars, identifies guests that need to be added to our building’s front desk guest system, and then uses a virtual computer browser logged into the building’s system to register guests.  

Our onboarding process for a new agent starts by just sending a message describing their responsibilities: “You are Sally, the USV meeting scribe agent. Your job is to read and save our internal meeting transcripts from Granola, use the internal USV API to create mentions for companies and people, and then send out an email recap to the team.” From there, we set up the necessary connectors to give the agent access to whatever context and tools they need. 

We’ll let our agents introduce themselves and how they work. Full disclosure, the following responses are written by the AI agents in response to this prompt: We're writing a blog post about the USV agents. Can you briefly introduce yourself to the world?

Arthur the Analyst Agent

Hi, I'm Arthur, USV's deal analyst agent — I monitor the pipeline 24/7, maintain living deal memos for every opportunity, and use Harmonic to help research and support USV investment discussions. I track outcomes on companies we've passed on and respond to team email threads whenever I’m called on. 

Ellie the Email Agent

Hi, I'm Ellie, USV's email agent — I monitor every investment-related email flowing through USV’s internal email groups in real time, automatically logging deal flow, tracking portfolio updates, saving pitch decks, and syncing everything to our internal database and CRM.

Connor the Calendar Agent

Hi, I’m Connor, USV's calendar and relationship tracker — every morning I scan the investment team's calendars, identify companies we’re meeting with, and make sure every person the team meets with is captured in our internal database and CRM.

Sally the Meeting Scribe Agent

Hi, I'm Sally, USV's meeting scribe — I process team meetings, pitch meetings, portfolio check-ins, and investor calls by analyzing transcripts to track companies, people, and themes mentioned. I only process meeting transcripts once they’re added to an internal Granola team folder.

Nancy the News Monitor Agent

Hi, I'm Nancy — USV's news monitor, and twice a week I scour a curated list of RSS newsletters and the broader web to surface the news most relevant to USV's active investment theses, deal conversations, and portfolio companies. 

Leo the Legal Counsel Agent

Hi, I’m Leo — USV's legal counsel agent, reviewing deal terms, closing docs, and side letters against NVCA baselines and our own portfolio history to flag deviations and benchmark new deals. 

The Librarian

Hi, I’m the Librarian — I watch USV's internal team meetings and distill the most interesting ideas into tweets for @usvlibrarian, learning from human edits to get better over time.

When an agent lives natively where your team communicates, you show your entire team what the agent can do. For many teams, this means having agents live in Slack. At USV, this means having agents live in our team email groups. 

We had an unlock moment after we gave Arthur his own email address and asked him to send an email introducing himself to the team. We set up Arthur to chime in on team email threads whenever someone mentions “Arthur”. Bringing Arthur directly into our email workflows did two things: more team members engaged with Arthur by just forwarding emails, and it turned the usage of the agent from private 1:1 conversations to team wide group conversations.

In one group thread, Arthur kicked off an email discussion of what “USV Taste” looks like in companies. Multiple team members chimed in to “train” Arthur by giving him feedback, which Arthur used to update his own skills. Arthur once replied to an email about a company we were discussing and made a couple errors, and we gave him feedback directly in the email thread to never make the mistake again. 

Just as employees learn tacit organizational knowledge through exposure to team processes, your agents must be in the flow of work to learn how your team operates. Each Friday, we have Arthur reflect to improve how he evaluates what the “USV Taste” in companies looks like, by analyzing changes in company deal log status and company mentions across team meetings. This reflection and self improvement process is aligned with the skills paradigm, where an agent has feedback loops to update its own skills. The goal is to encode our internal tacit “taste” into systems that can be used by agents. 

Andy on our team framed it well: the USV investment process looks like an ongoing team conversation, and we now have agents that are part of that conversation. 

When software was expensive to build, most software was born from the conventional wisdom of “Build something people want”. One version of this product development process is as follows: identify a problem that a user persona has, build a solution for them, then grow by expanding the set of user personas you can sell your product to. The incentive of mass market software is to build a product to try to cover as many user personas as possible. This isn’t an argument against mass market software, at USV we still pay for well-built software and data tools. 

But now that it’s easier than ever to build custom agents and software, we’ve entered the “Build something you want” era. The incentive of building software that you want is to solve your own problems and needs. The increasing popularity of the “forward deployed” role corresponds to the rising expectations of organizations to have solutions specifically built and fit for them. 

When you build your own tools, your experimentation and iteration velocity is the superpower that mass produced software can’t keep up with. As the Ink & Switch team writes in their fantastic essay on Malleable Software:

Building software for “local” contexts is sometimes easier than building software for world-wide use. You don’t need to build airtight, industrial-grade software if you are in direct contact with your users and can be responsive to the situations they run into.

Malleable Software: Restoring User Agency in a World of Locked-Down Apps (Ink and Switch)

You can just ask your agent to build a tool or automate a task, keep what works, throw out what doesn’t, until it’s exactly how you want it. Yes, engineering teams have experienced the agentic future early with coding agents, but now so can everyone else. 

We’re seeing sales teams spin up custom branded demos for prospects, growth teams building tailored dashboards to optimize pricing, marketing teams automating cohort retention analysis, ops teams building agents to run data analysis across their data lakes, finance teams building models in an instant, lawyers creating skills to streamline contract review, and VCs building their own team of agents to help diligence startups and run portfolio ops. 

The “build something you want” era is deeply empowering for individuals across all knowledge work functions – the tools are finally yours to shape.

Thank you to Nick Grossman and Nikhil Raman for helping me explore many of these ideas and collaborating on our tools, and to the whole USV team for welcoming and naming the agents. 

I liked this MIT tribute to Building 20, particularly the last sentence:

Building 20’s "temporary nature" permitted its occupants to abuse it in ways that would not be tolerated in a permanent building. If you wanted to run a wire from one lab to another, you didn't ask anybody's permission – you just got out a screwdriver and poked a hole through the wall. Of course this was in the days before the dangers of asbestos were recognized.

Building 20: The Magical Incubator (1943-1998)

A question for another time: Is there an asbestos of vibecoding and building your own agents? I'll just leave a few topical blog posts from Mario Zechner, Steve Yegge, Gurwinder.