Wink Pings

Grep Lets a Thousand Agents Research Companies at Once: Can 100,000 Clients' Worth of Work Be Done in 33 Hours?

Grep.ai opens swarms to everyone. It breaks tasks into stages, with a manager agent coordinating thousands of worker agents; mechanical work runs as code, and only judgment calls invoke models. In a bank compliance case, one person's 25 years of inspection volume can, under the algorithm described, be compressed into tens of hours. It sounds like an electronic workstation, but this is exactly the kind of bill enterprises often pay.

Grep.ai this week opened swarms to everyone. Garry Tan shared Miguel Ríos Berríos's article. Miguel is Grep's founder and CTO; he previously ran platform engineering at Brex and data science at Twitter. The article covers the technical implementation, current usage, and their view of the future. Simply put, one Slack message can spin up thousands of agents to do work, and that picture is more worth watching than “yet another agent feature.”

LLM calls plus tools, put into a loop, become an agent. skills, MCP, and sandbox make this loop more usable, but it is still a loop: input goes in, the agent works toward the goal, and a result comes out. Miguel treats the swarm as the next layer: give a group of agents a goal and let them finish it together. Some people may think a swarm means taking a list and putting one agent on each row. The article explicitly rejects that understanding. Batching can be part of a swarm, but an effective swarm needs stages, agents with different specialties, and a coordination layer. The coordination layer is a manager agent running on a frontier model, responsible for the goal from start to finish.

The lead-gen swarm they run themselves is like a table that fills itself in. The first stage finds companies by ICP, with one agent per region, then merges and deduplicates. In the second stage, one agent per company simultaneously checks what it sells, whom it is hiring, and what management has recently said. Each agent can only fill columns in its own row, so a thousand agents will not mix up companies. In the final stage, one agent reads all the results, writes reports by segment, and writes sales packets by company. Merging and exporting tables use ordinary code, cost zero, and do not hallucinate. The research step actually consists of three agents: company, growth signals, and point of contact. There are five agents under the manager. Not every step needs a full agent. Agents can first learn the task on a small number of companies, write it as a workflow, and run the workflow on the rest of the list; the article says this is up to 90% cheaper per company. Hard cases still go to a full agent. This detail is critical; whether a swarm is cost-effective depends on it.

The manager is an asynchronous agent that ticks. A swarm can run for hours, and keeping a frontier model awake watching progress the whole time is wasteful. The manager wakes up, reads state, advances, and sleeps again. In each tick, mechanical actions run as code: start a stage when inputs are ready, collect results when agents finish, do joins and exports. The model only wakes up for judgment calls, such as what to do if forty companies come back empty, or whether to ask you if the plan is missing the goal. Budget caps stay in code; the model cannot argue with them. This design is closer to an operable system than “let the model manage everything.”

Messages have three routes. The manager sends instructions to an individual agent or an entire stage, for example: stop searching the whole web and go straight to page two of the state registry to get the executive list. Agents share findings with one another: one parent-company filing lists subsidiaries, and relevant agents skip the search. Agents escalate questions to the manager. Underneath is an inbox; messages advance the current transcript, and the manager reads it on the next tick. The mechanism is not fancy, but it determines whether a swarm is more resilient to change than a static workflow.

The external interface is designed for agents. The main entry point is Grep MCP. Brain chat on the web can also launch it, but most internal swarms start from Claude Code, Codex, or a Slack mention. A swarm is an MCP Task: your agent starts it, gets a task id, checks progress, and retrieves deliverables. MCP Events let agents subscribe to signed callbacks and get notified on completion, attention needed, or cancellation. Seven calls cover prepare, validate, quote, approve, view, records, and retry. Developers can think of it as a long-running task API for agents.

The first use case is banking. A hundred thousand enterprise customers have not been re-reviewed for years. Is the company still alive? Does it have a website? Does it still sell what it said it sold back then? A light check takes thirty minutes per company; 100,000 companies is 50,000 hours, equivalent to one analyst working for 25 years. Hire a hundred people, each with about three months of work, plus two to four months to build the team, and it takes about half a year, with ongoing payroll. After running the numbers, the bank's rational choice is to skip the check and keep carrying assumed risk. Miguel's argument is that swarms rewrite this arithmetic. Write the check once, run it across the entire portfolio, one agent per company, and a final agent reads the results and gives recommendations. According to the numbers in the article, one swarm today handles at most 10,000 companies; 100,000 companies means ten swarms, and one agent can launch them all. A deep research agent takes about twenty minutes per company; with 1,000 concurrent, 100,000 companies takes about 33 hours. The cost per check is about one-twentieth of half an hour of an analyst's time, before counting learned workflows. There is a bit of irony here: enterprises will not necessarily pay for “smarter AI,” but they will pay to turn unmeasurable risk into a calculable cost.

Another direction is growth. ICP identifies hundreds or thousands of companies, and one agent per company looks for growth-bottleneck signals: Is the company hiring lots of operations people? What pain points has management mentioned in earnings calls, interviews, or on LinkedIn? A final agent packages the results by company or by segment. Traditional enrichment cannot provide this, because each row is a small piece of deep research.

Miguel argues that swarms have no human analogy. Humans can coordinate at scale: stadium singalongs, national voting. But each person does something simple and does not need a neighbor's findings. Humans have never put ten thousand skilled knowledge workers on the same knowledge work, let them share findings while working, and gotten results the same day. The closest thing is BPO, contingent labor, where a new team takes two to four months to run smoothly. A swarm can launch thousands, hundreds of thousands, or theoretically millions of agents with frontier intelligence and tools from a single message. That claim is big, but the article does not package it as something that has already happened. Miguel also admits the biggest use case is still unknown. Give a GPU to people from the early computer era, and they will only speed up existing math; they will not think of video games or training large models. Swarms are at that stage now; the use cases in the article all look like accelerated versions of known work.

A commenter picked up on a small point: one filing saves thousands of searches. Another reply said they have waited a long time for a framework that can use agents at scale. What Grep opened this time is an early product, not mature infrastructure. For developers, what is worth watching is the coordination layer, inbox, MCP long-running task interface, and workflow learning; for general readers, what is worth watching is the cost math, not the demo videos.

Sources:

发布时间: 2026-10-29 04:36