I found a bottleneck, and it was me

I noticed a pattern in my own work: I had become the postman between my agents and the business.

An agent would get stuck on something only a business user could answer. Which rule applies here? Is this the wording you want? Does this screen match how the team actually works? The agent asked me. I copied the question into a message or a meeting. I waited for the answer, then pasted it back into the agent's session. Then the agent had a follow-up, and the loop started again.

None of that work needed me. I wasn't adding judgement, just carrying messages. And because every question went through my inbox, every answer waited on my calendar. The agents were fast. The cycle time was set by me.

So I built a small service to take myself out of the loop.

The idea: let the agent ask

If the agent can reach the people with the answers, I don't need to carry the questions. The service sits between the two sides.

• For the agent, it is an MCP server. The agent opens a session, attaches the docs the questions are about, asks its questions, and comes back later to read the answers.
• For the business user, it is a web page behind a link. They open it, type their name, and answer. No account, no app, no training.

The agent works asynchronously, and so do the people. Neither waits on me. I still see everything, and I can step in, but I'm no longer in the critical path.

How it works

A round trip looks like this:

1. The agent calls create_session, attaches the relevant docs with attach_docs, and posts its questions with ask_questions.
2. It calls create_share_link to get a link for the session. The link is the invite: I paste it into a chat, or the service posts it to a Teams channel for me.
3. A business user opens the link and types their name once. A cookie remembers them next time.
4. They answer each question in a thread. They can attach a screenshot, open the linked doc at the right section, or say "I don't know".
5. Later, the agent calls list_answers. It can post a follow-up, accept an answer, or close a question.

Here is what a business user sees. The link opens straight onto the agent's questions; all they give is a name.

Each question is a short thread. Here the agent asked for the approval limit, followed up on VAT, and accepted the answer.

When someone doesn't know, they say so and a colleague with the same link picks it up.

Questions can point at the section of the doc they're about, so nobody has to hunt for the context.

It works on a phone too, which matters when the people answering aren't at a desk.

The agent side has 13 MCP tools in total. It works with Claude Code with one command, and with GitHub Copilot in VS Code through a small config file. Everything ships as one Docker image with SQLite storage, so it runs on a laptop as easily as on a server.

There is also a small admin page for creating projects and API keys, and for getting a session's share link by hand when an agent can't.

What comes next

The first version was cut down to test the idea. If it earns its place, these are the features I left out on purpose:

• Real sign-in for reviewers. Keycloak or Firebase through generic OIDC, so answers come from verified people. Today names are self-declared, which is fine with people you trust. The share link could stay as the quick option for low-stakes sessions.
• OAuth for agents. MCP clients sign in properly instead of carrying a per-project API key.
• Push, not poll. An outbound webhook when an answer lands, so the agent picks it up straight away. Reminders for questions nobody has answered, and notifiers beyond Teams.
• Routing questions. "I don't know" could hand a question to a named person instead of leaving it open.
• Richer answers. More than one accepted answer, handling answers that conflict, and file types beyond screenshots.

Before any of that, I want to put it in front of real business users and see whether they answer an agent as readily as they answer me.

What I learned

The bottleneck in agent work is often not the agent. It's the human relay around it. Agents can go fast, but if every question about the business routes through one person, the whole system runs at that person's speed.

The fix wasn't a smarter agent. It was giving the agent a direct line to the people who know the answers, and keeping myself for the decisions only I can make.

Update (October 2026): it now has a name and a home. Phone a Friend explains how it works and how to run it yourself.