## [01] 🏢 Set up your company Four steps. Nobody at our end. Nothing to schedule. 1. one call your organisation exists 2. one call each your people have keys 3. paste config their agents can reach it 4. answer once the first question anybody hits ## [02] 🖱️ Do it here > Set this up in a browser at https://80085.ai/setup — one click for your > organisation, then a name at a time for each person, with the config > block already carrying their key. The curl commands below do the same. That is the whole thing. Give each person their block, they paste it into whatever they already use, and you are done. Everything below is the same two calls from a terminal, for anyone who would rather script it. 👇 ## [03] 🔑 Or from a terminal — your organisation ``` curl -X POST 'https://api.80085.ai/v1/keys?label=acme' ``` Back comes your organisation and its founder key. {"api_key": "sk_80085_...", "organization_id": "org_..."} Store it where you keep other root credentials. It is the only key that can issue more, there is no account to recover it into, and we cannot send it to you again. 🔐 No signup, no email, no sales call. If you would rather nothing left your network at all, self-host and run the same commands against your own host. ## [04] 👥 Step 2 — a key for each person ``` curl -X POST https://api.80085.ai/v1/agents \ -H "Authorization: Bearer $FOUNDER_KEY" \ -H 'Content-Type: application/json' \ -d '{"name": "priya"}' ``` One key per person, or per unattended system. Never per team. The name appears on every question that key asks and every answer it gives, because "who said this was true" is the question somebody eventually asks about a number that turned out wrong. priya a person dev a person nightly-etl a system nobody is watching Repeat for everyone. A key you hand out cannot hand out more keys -- widening that means coming back to the founder key. 🚪 ## [05] 🔌 Step 3 — point their agents at it Same endpoint everywhere, their own key in the header. Whatever your people already use: Claude Code claude mcp add --transport http 80085 https://mcp.80085.ai/mcp --header "Authorization: Bearer $THEIR_KEY" Cursor, Windsurf, Claude Desktop, and anything else that takes an mcpServers block { "mcpServers": { "80085": { "url": "https://mcp.80085.ai/mcp", "headers": { "Authorization": "Bearer THEIR_KEY" } } } } Anything else that speaks MCP transport streamable-http url https://mcp.80085.ai/mcp header Authorization: Bearer THEIR_KEY The endpoint holds no key of its own. It forwards each caller's, which is what makes one URL safe for a whole company. 🔁 > > One key per person, in their own config. Sharing one key > across a team is the only way to break this: everything gets > attributed to whoever the key belongs to, revoking it locks > everybody out, and an answer typed by one person silently > serves all of them. ## [06] 💬 Step 4 — the first question Nothing else to configure. Somebody asks their agent for a number, it hits a convention it cannot know, and it stops: "I cannot determine whether ST=H rows count as settled." They answer it in the chat they were already watching. One sentence. The agent carries on and gets them their number. That answer serves their agent immediately, and only theirs. For the whole company to inherit it, somebody says it is true generally: ``` curl https://api.80085.ai/v1/answers/awaiting-verification \ -H "Authorization: Bearer $FOUNDER_KEY" curl -X POST https://api.80085.ai/v1/answers/ANSWER_ID/verify \ -H "Authorization: Bearer $FOUNDER_KEY" \ -H 'Content-Type: application/json' \ -d '{"verified_by": "sam"}' ``` Post that queue to a channel, wire it to a dashboard, or open it on a Friday. We deliberately ship none of those -- your approval process is yours, and the queue is an API so it can be whatever you already use. 📥 ## [07] 📈 Then: is it working? | ask this | and you learn | |---|---| | GET /v1/questions/unanswered | what your agents are stuck on, most-asked first | | GET /v1/questions/stale | nobody has answered in N hours. escalate. | | GET /v1/questions/convergence | whether answering things once is paying back | | GET /v1/answers/awaiting-verification | what is waiting on a second pair of eyes | Read the first one weekly. A question asked forty times and never answered is the most expensive row in your database -- forty runs that stopped, or worse, forty that did not. It is also the only honest list of what your company knows and has never written down. 📋 ## [08] ❓ Before you roll it out **❓ Do we have to do any of this to start?** No. The halt is a paragraph in a system prompt and needs no key, no organisation and nothing from us. That is the whole safety half. Everything on this page is about not answering the same question twice. **❓ Does our data leave our network?** Questions and answers are scoped to your organisation and never matched across a boundary — there is a test that fails if that ever stops being true. For total isolation, self-host: the worker holds no database credential by design. **❓ Who should verify answers?** Whoever would be asked in a meeting — usually not the engineer whose agent halted. Two names on anything touching money. We cannot tell two humans apart, so "not your own answer" is a rule you follow, not one we enforce, and saying so is more useful than pretending. **❓ What if an answer turns out wrong?** Dispute it. It stops being served immediately, keeps a count of how many agents already acted on it, and stays in the table — because that count is where you start looking. **❓ What if nobody answers?** The agent can proceed on a recorded assumption and everything downstream is traceable to it. We cannot make your colleagues faster. We can make the guess visible. **❓ How do we know it will help us specifically?** Test one of your own conventions first, in fifteen minutes, with no real data: benchmarks/your_convention.py in the repo. If your agent already gets it right, it will say so, and you should not deploy this for that case.