Model or dataset
browser-use/agency avatar
browser-use/agency

browser-use/agency: a local card feed where your coding agent proposes the work

Agency card feed: agents finish work, Magnus decides with one click

386 stars19 forksTypeScriptLicense varies

At a glance

What is it?
Agency is a local, single-user Next.js app plus one agent skill that turns your prompts, messages and repository context into a stack of decision-ready cards. It is a coordination layer for one trusted operator, not a hosted service.
Who is it for?
Adopt Agency if you already run a coding agent on your own machine, you want its output shaped into reviewable cards, and you accept that the app has unauthenticated routes and must stay on loopback. Skip it if you need a multi-user service, a hosted deployment, or an unattended background worker; the README states there is no installed background worker, no automatic thread injection and no built-in connector wizard.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 7 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem Agency targets: work that never gets picked up

Most agent tooling optimizes for producing text. Agency optimizes for producing decisions. The README describes it as something that "finds useful work" and "prepares fixes, replies and ideas", which is a different job from answering a prompt: the agent has to look at your actual context, decide what deserves attention now, do the small piece of work, and then stop at a card that shows the result and the remaining decision. The intended reader is one person who already uses Codex or Claude as a daily driver and wants the agent's output to arrive as a reviewable artifact rather than a chat transcript. The repository is a TypeScript project with a Next.js-style app directory, a Drizzle schema under db/ and drizzle/, a worker/ folder, and a skills/ directory holding the single Agency skill. Nothing in the README suggests a team workflow. The app is explicitly a "trusted single-user app with unauthenticated routes", and the README repeats the point: keep it on loopback, do not bind 0.0.0.0, do not put it behind a public tunnel. That constraint is the product, not an oversight. If you want a shared inbox for a support team, this is the wrong shape.

How the card feed actually works: skill, coordinator, SQLite

The mechanism is split between a web app and a skill file. The app is a local server that renders cards and stores state; the skill, at skills/agency/SKILL.md, is the instruction set a coding agent reads before it does anything. The README's flow is: the active coding agent reads jobs from the app, assigns subagents to research and prepare cards in parallel, and one coordinator handles duplicates and approvals. The agent learns your context from your brief, your relevant Codex or Claude prompts, your feedback and past work, keeping a few short examples in a private profile rather than a full transcript archive. Startup is a discovery pass: the agent finds available connectors, APIs, CLIs and authorized sessions, then verifies a source with a live read before trusting it. The README lists Gmail, Slack, Granola, Calendar, repositories, support, analytics and Linear as examples of what those sources may be. Cards are the interface contract. Each card must explain the full decision on its own, and the README distinguishes the actions: Send approves the shown reply, Apply approves the shown change, and Merge requires the actual diff. That last distinction matters. A reply card carries the incoming message, a fix card carries the change, and a merge card cannot be approved without the diff in front of you. The app itself does not enforce your approval policy; the README says the agent reads the policy while the app does not enforce it, and that current explicit restrictions and runner rules take precedence. So the safety boundary lives in the skill and in your runner, not in the web server.

Installing Agency locally and getting the first ten suggestions

The README gives a four-command local setup. Node.js 22.13 or later and npm are required, and package.json pins the same engine floor. Clone the repository, install exactly the locked dependency tree, and start the dev server on loopback port 3100.

bash
git clone https://github.com/browser-use/agency.git
cd agency
npm ci
npm run dev -- --hostname localhost --port 3100

Open http://localhost:3100. The README states the local SQLite/D1 database initializes under .wrangler/, and that no Cloudflare account or hosted deployment is required. If port 3100 is already occupied, pick an unused port and set RADAR_URL to the server's actual URL; the README also says to reuse the intended checkout and server rather than starting a second one. Next, install the skill into your agent's skill directory. The installer refuses to overwrite an existing installation, so review and back up any copy you already have; a new agent session is what loads installed changes.

bash
node scripts/install-skill.mjs --codex
# Or:
node scripts/install-skill.mjs --claude

The README's own starting instruction for the agent is a short prompt you paste into the coding agent: point it at the repository, tell it to start Agency, and ask it to create a me.md file and make the first 10 suggestions. The agent infers a short editable profile from relevant context and creates the first cards. One caveat the README states in bold terms: the Save dream button saves that brief and does not launch an agent. The website is where you write the dream; the coding agent is what acts on it.

Where Agency breaks down, and where it is simply the wrong tool

The sharpest limitation is the trust model. Unauthenticated routes plus a browser that can reach your signed-in sessions is a combination that only works on a machine you control. A private repository does not protect an exposed server, and the README says so directly. The second limitation is architectural: a cloud worker cannot automatically reach your laptop's localhost, your files, or your signed-in browser. If your agent runs in a hosted runner, the card feed cannot see the same context the README assumes. Third, the cadence is opt-in and manual. You can agree to a four-hour cadence, and the agent then uses its runner's scheduler, reuses any matching schedule and records the real checkout, app URL, profile and approval paths. But the README is explicit that a cadence written in a profile does not itself run anything. There is no installed background worker. If you expect Agency to keep working while your laptop is closed, it will not. Fourth, the package starts empty by design: no personal profile, tickets, customer media or credentials ship with it, and installation grants no service access and creates no worker or schedule. That means the first hour is setup, not output. The README even draws a line around it: setup chores do not count as suggestions. Finally, the approval policy is documentation, not enforcement. If you write a permissive approvals.local.md, the agent may follow it, and nothing in the app will stop it.

How Agency differs from a scheduled agent runner or a chat assistant

The nearest comparison is a general agent runner such as a Codex or Claude session driven by a cron-like schedule. Those tools execute a prompt on a timer and hand you a transcript. Agency inverts the ordering: the card is the unit of output, and the agent must attach the evidence, the exact draft and the decision to it. The README's layout rules make this concrete. The default asks for big graphics, short labels, original messages, exact changes and clear choices, with as little text as needed and supporting evidence behind an expand control. A chat assistant will happily produce a long answer; Agency is designed to produce a short card that stands alone. The other comparison is a connector platform that syncs Gmail, Slack and Linear into a shared workspace. Agency does discover connectors and verify them with a live read, but it does not present a shared workspace. It presents a private queue for one operator, with the agent as the worker and the human as the approver. If you want the shared workspace, Agency's loopback-only rule disqualifies it before features even matter. If you want a transcript you can scroll, the card format will feel like unnecessary ceremony.

Maintenance, upgrade cost and what the licence does not tell you

The repository is not archived, and the last push was on 2026-09-11, which is recent. There are no retrieved releases, so there is no versioned upgrade path to follow; package.json carries version 0.1.0 and the private flag is set to true, which means this is not published to a registry as a consumable package. Upgrades therefore mean pulling the checkout and re-running npm ci against the lockfile. The installer's refusal to overwrite an existing skill installation is the one upgrade hazard worth planning for: you must review and back up your installed copy before updating, and changes only load in a new agent session. Your private files, me.md and approvals.local.md, are Git-ignored, so a pull will not clobber them, but a fresh clone elsewhere will not carry them either. The licence field is unknown in the repository metadata provided, and the README does not state a licence. Treat that as unresolved rather than permissive: if you intend to redistribute the code, embed it in another product, or use it commercially, confirm the licence from the repository itself before you build on it. Nothing here is legal advice, and an absent licence file is not the same as a permissive one.

Editorial conclusion

Adopt Agency if you already run a coding agent on your own machine, you want its output shaped into reviewable cards, and you accept that the app has unauthenticated routes and must stay on loopback. Skip it if you need a multi-user service, a hosted deployment, or an unattended background worker; the README states there is no installed background worker, no automatic thread injection and no built-in connector wizard. Before you start, verify three things: that Node.js 22.13 or later is installed, that port 3100 is free or you have set RADAR_URL to the port you actually chose, and that your approval policy lives outside the repository at an absolute APPROVALS_PATH, because the app does not enforce that policy.

Frequently asked questions

How do I install browser-use/agency?

Clone the repository, run npm ci, then npm run dev -- --hostname localhost --port 3100. Node.js 22.13 or later and npm are required, and the local SQLite/D1 database initializes under .wrangler/ with no Cloudflare account needed.

How do I use browser-use/agency once it is running?

Open http://localhost:3100, install the Agency skill with scripts/install-skill.mjs, and keep one coding-agent session responsible for Agency using the README's prompt. The agent reads your brief and past work, prepares cards, and you approve with Send, Apply or Merge.

What does browser-use/agency mean by agent cards?

Each card shows the result of a piece of prepared work and the remaining decision, and must explain the full decision on its own. Send approves the shown reply, Apply approves the shown change, and Merge needs the actual diff.

Does browser-use/agency need a Cloudflare account or a hosted deployment?

No. The README states the local SQLite/D1 database initializes under .wrangler/ and that no Cloudflare account or hosted deployment is required.

Can browser-use/agency run as a background worker on a schedule?

There is no installed background worker. You can agree to a four-hour cadence or choose another, and the agent then uses its runner's scheduler, but the README states a cadence written in a profile does not itself run anything.

Can browser-use/agency be exposed on a public URL for a team?

No. The README describes it as a trusted single-user app with unauthenticated routes and says not to expose it with 0.0.0.0 or a public tunnel, adding that a private repository does not protect an exposed server.

Official sources

  1. browser-use/agency on GitHub
  2. Issues
  3. README
Community notes

Community notes