Stop Building AI Agents. Build AI Employees Instead (Live Demo) | Pedro Franceschi

In this Peter Yang interview, Brex co-founder Pedro Franceschi demonstrates what he calls virtual employees. The examples connect a specific recurring job with persistent context, tools, feedback and infrastructure, rather than starting with an agent that could do anything.

He frames a product organization's effectiveness as the time between noticing a customer signal and putting a working response in front of the customer. AI can help compress that loop by making unstructured customer information easier to examine and prototypes cheaper to produce.

That does not make choosing a problem unimportant. Franceschi says engineering, design and product should have equal standing, with roles increasingly overlapping. PM work includes understanding customer and go-to-market context, making trade-offs and checking that the result addresses the original pain. When more things can be built, he argues for concentrating on the few that matter.

Franceschi describes spending much of his own time reviewing work. He compares the quality standard to case law: concrete reviews show the organization what good work looks like, from leadership down to individual contributors.

The team separates problem alignment from solution alignment. First ask which problem is worth solving; then examine the proposed response. Customer calls, lost deals and requests can inform that choice, but a pile of summarized data is not itself a decision about company priorities.

Shared skills encode recurring questions about principles, alternatives and bottlenecks. Running those before a review can handle a common first pass, leaving people to spend time on what is specific to the problem. The skills need maintenance too; Franceschi says he and the product leader work on keeping them accurate.

The recruiting example, Jim, has an identity people can interact with in Slack and a web interface. Franceschi says it had been running since February at the time of the interview.

Its pipeline syncs with Greenhouse, ingests applications, parses resumes and enriches context from sources such as professional profiles and GitHub. Candidates are evaluated against role-specific criteria. The surrounding system retains candidate state and the connections needed to perform that work.

The point of the employee metaphor is that a recruiter can ask a work question without first assembling a generic prompt and every tool connection. Franceschi also emphasizes the infrastructure built around the skills to make that interaction behave as intended.

Jim's responsibilities are sourcing, filtering inbound applicants and providing an analytics layer. The demo includes asking about roles, reviewing candidates that need action and configuring recurring sourcing for a role.

The criteria are part of the system, not an unchanging judgment hidden in a model. People can inspect role-specific evaluation and give feedback about decisions they consider wrong. The team also uses scheduled work and proposed improvements to develop the workflow over time.

Franceschi says Jim can contact candidates on behalf of a recruiter or sourcer. That is one reason the system needs controls around actions, rather than treating a colleague-like interface as sufficient evidence of reliability.

The team examines cases where recruiters advanced someone the agent rejected, and cases the agent considered strong but people did not pursue. Those disagreements can identify places to investigate and improve the process.

Agreement is not presented here as a substitute for understanding the decision. It is a way to inspect the relationship between human work and agent work, with concrete examples rather than only a claim about productivity.

The hiring discussion also includes a nuance about open-source contributions: Franceschi says their presence can be a useful signal, but their absence is not itself a negative signal. He describes a practical building exercise in interviews, rather than treating a public profile as the whole assessment.

22:40View full image

At 22:40, the original dashboard displays disagreement categories. Agreement with a recruiter is not proof of a correct hiring decision.

Franceschi then demonstrates Crabtrap, which he describes as an open-source proxy controlling an agent's network traffic. His concern is that an agent capable of executing code has more possible actions than a short list of tool descriptions suggests.

In the demonstrated approach, static rules handle requests that should always be allowed. Other requests are evaluated against a policy by a model. The interface shows an audit trail and the basis for an allow or block decision.

Observed traffic can also be used to suggest a policy. Examples of prohibited actions include deleting repositories, changing identity-system configuration or changing policies. This is the approach described in the demo, not a proof that a model judge or a generated policy eliminates every security risk.

24:40View full image

At 24:40, the original demo shows a network policy with static rules and model evaluation. This is the demonstrated policy interface, not an independent security audit.

The cost-analytics demonstration separates corporate AI used by employees, operational AI used in business processes and AI in customer-facing products. It then lets the team inspect models, callers, people and customer-related costs.

A cost-per-call trend can reveal a change that a total bill hides. Caching and model choice can affect that trend, while a caller-level view helps identify which process changed. Franceschi explicitly says some of the displayed data is demo data, so the example numbers should not be treated as a verified account of the company's actual spending.

He also describes a product direction: connect usage analysis with the dollars leaving a company's account. Usage and settled payments are different parts of the picture, and he wants them reconciled before a company decides where to act.

Asked about budgets, Franceschi describes broadly permissive experimentation with some caps. His sequence was to let people go deeply into AI, understand what value and usage emerged, and then optimize specific lower-productivity areas.

That can mean improving caching or using a cheaper model for a suitable task. The argument depends on knowing the use case; simply consuming many tokens is not the same as doing valuable work.

He also notes that token consumption can arrive indirectly through software products, not only through contracts with model providers. Understanding cost therefore means looking across tools and workflows, rather than declaring the organization a single-provider shop.

Franceschi's personal Autopilot demo starts with people and programs he cares about. Signals from Slack, email, meetings and documents are collected and used to update their state.

The interface gathers status, blockers, risks, interaction history and proposed action items. A message asking about an event can become a draft decision item, while the original signal remains available to inspect. It is a way to return to context without rereading every channel separately.

He says the underlying records are Markdown files committed to a repository, with scripts providing a more convenient interface. He also acknowledges that making the setup reliable takes time. The smooth demonstration sits on top of that work.

The interview closes with a distinction between selling a tool and selling work performed through an agent loop and tools. Franceschi argues that the customer still pays for a problem being solved, even if the mechanism and pricing change.

The examples explain what that requires in practice: a focused responsibility, usable state, inspection of mistakes, action controls and cost visibility. The “employee” framing describes how the work is organized and experienced; it does not make the supporting engineering disappear.

Adapted from Peter Yang's interview with Pedro Franceschi, “Stop Building AI Agents. Build AI Employees Instead.” Internal systems, product plans and cost policies are descriptions from the interview, not independently verified current product specifications.