Solutions

What teams actually use it for.

An alert channel, a repository, a cloud bill, a sprint board, a calendar, an inbox, a month-end close. The asks are written the way people type them, and every answer is the product doing what it does today — the calls it makes, the writes it stops at, the things it will not do. Each one opens onto its own page: the tools it ran, what the console needs, and what it refuses.

Try it now Deploy it yourself Watch it run

Names, figures, repositories and customers are changed. The mechanism under each case is not: the endpoints, the held writes and the refusals are what the product really does — including the two places the first answer was wrong and the second corrected it.

On-call & monitoring Engineering Cloud & cost Projects & sprints Daily operations Meetings & scheduling Email & follow-ups Finance & ops

On-call & monitoring

The alert lands. So does the answer.

Invite it to the channel your alerts post to. Mentioned under one, it has the payload, the production logs and the last week of the channel before it says a word — through a service account that can only read.

monitoring-prodthread

Sam

@attest_tag check what happened here — the doc id is in the alert above

attest_tagApp

The extraction failed because the extractor API returned HTTP 500 on every attempt, about 90 seconds apart, until the workflow ran out of retries. Five attempts between 19:53 and 19:59 UTC; the body is the generic gateway error page, so the fault is on the service, not the document.

Triage the alert in the thread it landed in.

It reads the alert, queries the production logs for that document id through a read-only service account, and comes back with the failing call, the timeline and where the fault sits — in the thread, where the on-call person already is.

A failure the error message already explains gets explained from the message: a European-formatted amount that a float parser refused was diagnosed without a query spent for show.

gcp_query_logs
read_thread

monitoring-prodthread

Dan

@attest_tag what's erroring in prod right now?

attest_tagApp

No single application failure in the last six hours. What is erroring is infrastructure: Prometheus rejecting out-of-order samples from remote write in the monitoring namespace, by far the most frequent, and a controller retrying a reconcile. The log query for each is below.

The state of prod, before anyone pages.

A plain question against the production logs: what is failing, how often, and whether any of it is the application. It groups the last hours by error and namespace and says which are noise, so the person looking can stop looking at the ones that are.

gcp_query_logs
run_js

monitoring-prodthread

Priya

@attest_tag look at all the alerts for this customer in the last 7 days and suggest what fix should be applied

attest_tagApp

Four alerts, all on the 7th, all the same failure: the custom validation on totalAmount throws on European-formatted amounts like 4.500,-. Normalise the thousands separator and the trailing ,- before the float() call and the whole set goes away.

A week of alerts, one fix.

It reads the channel’s history, groups the repeats by the field that keeps failing, and suggests the fix with the evidence beside it. Ask for every account that appeared in the alerts over 30 days and it lists them.

When its first pass missed a label the newer alerts used, the person asking said so, and it re-read the month and corrected itself — which is the behaviour you want from something reading alerts, and the reason the site’s guardrails page opens the way it does.

read_channel_history

stripe-alertsthread

Dan

@attest_tag find every message that says a customer unsubscribed and make a report of who unsubscribed and when

attest_tagApp

The unsubscribe report from #stripe-alerts: every subscription-cancelled event in the channel's history as a table — customer, date, price, the Stripe link and the thread it was discussed in — with one caveat: a channel read returns about 40 messages a call, so anything older needs paging.

A report out of a notification channel.

Webhook channels — Stripe events, sign-ups, cancellations — are a log nobody reads back. Ask for the report and it reads the history, works the dates and counts out in a sandboxed script rather than in its head, and posts the table. Ask for it as CSV and a file arrives instead.

read_channel_history
run_js
create_artifact

Engineering

Ask the repository a question. Then hand it the fix.

Connect the repositories a channel works on and it gets the GitHub tools for exactly those. The token never leaves the proxy, and the first thing every team asks — what can you reach? — is answered from the channel's own list.

paymentsthread

Sam

@attest_tag what changed in the payments client since Monday?

attest_tagApp

3 commits on main since Monday, all by Sam: jittered backoff between attempts (Thu), the retry count replaced with a 2.5 s total time budget (Wed), and the timeout error made retryable (Tue) — each one linked.

What changed since Monday, with the commits linked.

Recent commits and pull requests across the connected repositories, each linked, the author named, the messages summarised into what actually changed. Follow up with “which PR touched the retry budget?” and it searches the code rather than guessing. Eighteen repositories connected to one channel is an ordinary setup.

github_recent_commits
github_find_code
github_get_pr

paymentsthread

Priya

@attest_tag fix the flaky retry-budget test so it stops depending on wall-clock time, and raise a PR

attest_tagApp

Fix job queued — needs your Confirm (buttons below, expire in 5 min). Repo acme/payments, base main. It will move the test onto an injectable clock instead of real sleeps, keep the coverage, and open a draft PR. Acceptance: the suite passes ten runs in a row.

“Fix it and raise a PR” — and a draft PR arrives.

The brief is held for a Confirm that names the repository, the base branch and the change. Then a separate container clones the branch, runs the tests, makes the change, runs them again, and opens a draft pull request carrying the brief, the evidence and the results before and after. It may push one branch. It never merges.

start_fix_job

paymentsthread

Dan

@attest_tag what did we decide about retries this week, in three bullets? and who first suggested capping total retry time instead of the count?

attest_tagApp

Budget-based retries, not a fixed count: 2.5 s total per request with exponential backoff and jitter, replacing the proposal to go from 2 retries to 5, which Priya flagged as brownout risk. Jack suggested the cap first — Saturday, 10:07, in this channel, as a counter-proposal. A link on each.

The decision, who made it, and a link to where.

It reads the week’s threads and answers with a permalink on every bullet, and it names the person and the minute when you ask who said it first. Say “remember for this channel: checkout timeouts are tracked in #payments” and the next question starts from there.

read_channel_history
read_thread
remember

ml-internalthread

Mei

@attest_tag what did the extraction of this document cost, end to end?

attest_tagApp

Total cost of this extraction: $0.0668. The trace ran five generation calls in parallel, all on the same model — four table batches and one key-value pass — with input and output tokens and the cost of each in the table below.

Your own internal API becomes a tool.

An observability stack or an internal admin API with no preset is an ordinary custom connection: a host, a credential the proxy injects, a writes policy. It calls the API, totals the spans, and reports the figure with the trace it came from. A host that is not on the channel’s list — someone tried Stripe from a channel without it — is refused before the request leaves.

http_request
run_js

Cloud & cost

The cloud bill, answered from the metrics.

The GCP presets take a read-only service account and nothing more. Logs and monitoring are readable; nothing about the account can be changed through them — which is what lets you hand the channel to the people asking about cost.

cloud-costthread

Mei

@attest_tag how many VMs are running in testing and staging right now, and what do they cost a month?

attest_tagApp

22 VMs — 10 in testing, 12 in staging, all running and incurring cost. Testing: 6 cluster nodes, 2 app instances, 1 NFS server. Rough compute cost across both is about $1,420 a month; the always-on services are most of it.

Count what is running, and price it.

It queries Cloud Monitoring for the instances up in each project, groups them by what they are for, and works the monthly figure out from the machine types. The “app VMs” that turned out to be Cloud Run instances were explained as such — billed for what they use, not for existing.

gcp_query_metrics
gcp_query_logs
run_js

cloud-costthread

Priya

@attest_tag what are these six webhook instances, why are six running, and what do they cost?

attest_tagApp

Six identical webhook-handler VMs in a managed instance group, and six is the group's configured target size — so all six are always up. About $70 a month together. They average 1.5–2.5% CPU over the last 24 hours; cutting to two would save roughly $46 a month with almost no risk.

Why six are running, and what two would save.

It reads the instance group, the labels and a day of CPU, and puts the saving beside the recommendation. Resizing the group is a write the presets cannot make, so the decision — and the change — stays with a person, who now has the table.

gcp_query_metrics
run_js

cloud-costthread

Sam

@attest_tag which temporary environments are still up on the testing cluster?

attest_tagApp

11 namespaces with activity on the testing cluster, 7 of which look like per-feature environments — the t-prefixed namespaces plus the feature-tagged deployments — listed below with their pods and how long each has been up.

Find the environments nobody tore down.

Preview namespaces and per-feature environments are what a testing cluster fills up with. It lists them from the container metrics with their age and puts the count beside them. The tearing down stays with a person; it arrives with the list already made.

gcp_query_metrics
run_js

paymentsthread

Sam

@attest_tag 0.4% of checkout calls timed out. at 225,000 checkouts a day, how many is that per hour, per minute, and over a two-day weekend?

attest_tagApp

At 0.4% of 225,000 a day, computed in JS: 900 a day, 37.5 an hour, about 0.63 a minute, and 1,800 over the weekend.

Arithmetic it works out rather than recalls.

Totals, percentiles, date maths, a top-N over rows from an earlier tool call: it runs JavaScript in a sealed sandbox — no filesystem, no network, no credentials, ten seconds — and reports the numbers rather than a guess at them. In a channel with connections the script can also page through an API, read-only, and bring back just the count.

run_js

Projects & sprints

The board, from the thread.

ClickUp, Linear, Jira and Asana arrive as presets. Reads run; a new task is a card in the thread with the whole request on it, and a schedule is one sentence.

data-engthread

Sam

@attest_tag what's still open in Sprint 9 for the data engineering pod?

attest_tagApp

Sprint 9 (8–21 Sep) has 76 tasks still Open. The urgent ones first — two P0s with their assignees and links — then the rest, most of them unassigned audit findings.

Sprint status without opening the board.

It finds the list, pulls the open tasks with assignees and due dates, and answers where the question was asked. ClickUp also ships named tools, so the model calls a search tool rather than improvising against an API reference — the difference between an open-weight model that is reliable on the board and one that is not.

clickup_lists
clickup_search_tasks

paymentsthread

Priya

@attest_tag make a task for the retry change we agreed on, with the context from this thread

attest_tagApp

Drafted: “Replace retry count with a 2.5 s time budget in the payments client”, in the Backend list, with the decision and the link to this thread in the description. One write, so I'll wait — Confirm below.

A task with the thread's context, after a Confirm.

It drafts the task — title, a description written from the decision, the link back to the thread — and holds it. The card in the thread shows the exact call; Confirm creates it, Cancel drops it, and “Something else…” hands the thread back so you can say what you actually wanted.

clickup_create_task

paymentsthread

Dan

@attest_tag every weekday at 9am, post the questions in this channel that nobody has answered yet

attest_tagApp

Routine created: every weekday at 9:00 ET I'll scan the channel for questions without an answer in their thread and post a digest with who asked and a link — or say there are none. First run Monday.

The questions nobody answered, every morning at nine.

One sentence creates the routine. It runs in a fresh thread on the schedule, in your timezone, reads the last seven days, and lists each open question with who asked and a link. The console can edit it, run it now, or switch it off.

create_routine
read_channel_history

ml-internalthread

Mei

@attest_tag what happened in this channel this week? I was out

attest_tagApp

Recap of the past week: three active workstreams — the lookup enhancement (testing, pagination for the unified table, backward-compat checks), the release with tracing switched on, and the eval API — a cost concern flagged on Wednesday, and two decisions, each linked below.

The week in a channel, for whoever was out.

It reads the channel and its threads, groups the messages by workstream, names who is on each, and links the decisions — a recap written from the record rather than from whoever remembers it best. The same read is what a scheduled digest runs on.

read_channel_history
read_thread

Daily operations

The calendar, the inbox and the handbook — as the person asking.

Mail and calendar are never a shared credential. Everyone signs in for themselves, and one person's mailbox is unreachable from another's question. The refusal is in the proxy, not in the prompt.

design-teamthread

Mei

@attest_tag add Sam, Priya and Dan to Tuesday's design review — that occurrence only — and put the agenda in: five-file review

attest_tagApp

Please confirm — buttons below, expires in 5 min. I'll update Tuesday's occurrence of Design review only, leaving the series untouched: add the three as attendees, set the description to “Agenda: five-file review”, and send the invitations.

Change the meeting, and the invites go out.

Names become attendees through a contacts search, the event is found on your own calendar, and the change is held as a Confirm card naming the occurrence and the people. Press it and the update runs out of your account — invitations sent, the Meet link in the reply. An approver can press it for you; it still runs as you.

http_request

design-teamthread

Sam

@attest_tag get me Dan's last five emails and list who he's been talking to

attest_tagApp

Not Dan's mailbox — mail is only ever searched through the account of the person asking, and there is no token for his. Once you've connected your own Google account (I've DMed you the Connect button), I can pull your last five threads with Dan and list who else was on them.

Your inbox, as you — and never anyone else's.

Gmail is read through a sign-in you did yourself. Ask for someone else’s mail and it refuses, because the proxy holds no credential for their account and never will — a rule the model cannot be talked out of. Ask for your own and it reads, summarises and links, in a DM or in the channel you asked from.

http_request

people-opsthread

Priya

@attest_tag what's our policy on carrying leave into next year? check our docs

attest_tagApp

Up to 5 days carry into Q1 and expire on 31 March. Anything above 5 needs your manager's sign-off before 15 December, and contractors are out of scope. From the Employee handbook §4.2 and the 2026 policy update.

The handbook answer, with the page named.

Point it at a folder, a bucket or a shared Drive folder and it indexes the documents. “Check our docs” forces the search and an answer only from what it finds, with the document and the heading it came from. A document can be scoped to one channel, so the support handbook is not answerable from engineering.

search_docs

sales-opsthread

Dan

@attest_tag every day at 6am ET, find the leads created in HubSpot yesterday, research each one, and post a brief here

attest_tagApp

Routine created. Each morning it searches HubSpot for contacts created the day before, reads each company's site, drafts the outreach, and posts one brief per run in a fresh thread. Nobody is there to press Confirm at 6am, so its writes run pre-approved; ask and I'll hold them instead.

A morning brief from the CRM, researched.

A routine with a longer prompt: a HubSpot search, a web read per company, a draft per lead, one post. On the workspace that wrote it, it has posted every morning since. A routine’s writes are pre-approved by default, because a card posted at six is nobody’s to press — the person asking can have them held instead, and a write that needs an approver still goes to one.

create_routine
hubspot_search
web_search
fetch_url

Meetings & scheduling

The hour that suits four calendars, found by asking them.

Free/busy is one question put to everyone at once, not a read of anyone's events. A calendar that is not shared comes back as an error in that person's entry — which is reported, never read as free — and the booking itself is a card someone presses.

sales-opsthread

Dan

@attest_tag find an hour next week for me, Priya and [email protected], and book it — call it Q4 pricing

attest_tagApp

Please confirm — buttons below, expires in 5 min. Tuesday 23 Sep, 14:00–15:00 ET is the only hour all three of you are free next week. I'll put “Q4 pricing” on your calendar with a Meet link and invite Priya Raman (priya@…) and [email protected].

Find the hour nobody hates, and book it.

“Priya” becomes an address through a contacts search, and the hour comes from one free/busy call across the whole week rather than a read of three calendars day by day. The booking is held as a Confirm card naming the slot and the people; press it and the event is created out of your own account, with a real Meet link read back out of Google’s response.

http_request

design-teamthread

Mei

@attest_tag book the roadmap review with the four of us Thursday afternoon

attest_tagApp

Thursday 14:00–15:00 ET works for three of you. Dan's calendar isn't shared with you, so free/busy returned an error for him rather than any hours — I've treated that as unknown, not as free. Want me to book it and let him decline, or ask him first?

The calendar it could not see, said out loud.

A colleague whose calendar is not shared comes back from free/busy as an error in their own entry, not as an empty list of busy blocks. An empty list reads exactly like a free afternoon, which is how a meeting gets booked over somebody’s holiday. It is reported instead, and nothing is booked until the asker says which way to go.

http_request

attest_tagdirect message

Priya

every weekday at 8:45, brief me on today's external meetings

attest_tagApp

Routine created. Each weekday at 8:45 ET it reads today's calendar, picks the events with a guest outside the company, and DMs you one card each: who they are, the last thing they wrote to you, and the open deal. Reads only — nothing about the meetings is changed.

Five minutes before the call, who they are and what is open.

The chore is not the meeting, it is the ten minutes of hunting before it. Today’s events, the guests who are not colleagues, the last mail from each, and the deal record — assembled into one DM before the day starts. Every part of it is a read, so the routine has no writes to pre-approve.

create_routine
http_request
hubspot_search

proj-atlasthread

Sam

@attest_tag write up this thread into the Atlas status doc and open tasks for the two things we agreed

attest_tagApp

Please confirm — buttons below, expires in 5 min. Two writes: append a dated section to “Atlas — weekly status” in Drive (I'll export it, add the section and send it back, since a Google Doc has no bytes to patch), and create two ClickUp tasks in Atlas / This sprint.

The call is over; the doc and the board are not.

The write-up is the part that never happens. The thread is read, the doc is named with its link before anything touches it, and both writes are held on one card — so the reader sees the section that is about to be added and the two tasks that are about to exist, before either does.

read_thread
http_request
clickup_create_task

Email & follow-ups

The inbox, triaged and drafted — and never sent without you.

Everyone signs in for themselves, so one person's mail is unreachable from another's question. It drafts; it does not send. That is a habit the scope cannot enforce, which is why it is written here rather than only promised — Google has no draft-only permission to ask for.

attest_tagdirect message

Sam

what in my inbox actually needs me today?

attest_tagApp

Three need a reply from you, four are waiting on someone else, and eleven are notifications. The three: Northwind's PO split (5 days, no reply), the SOC 2 questionnaire (due Friday), and Priya's design review nudge from yesterday.

What actually needs you this morning.

Unread is not the same as needing you, which is why an unread count is useless by ten in the morning. The last day of mail is read as headers first, sorted into the three piles that matter — you owe a reply, you are waiting on them, nobody needs anything — and only the first pile gets spelled out.

http_request

attest_tagdirect message

Sam

draft a reply to Dan about the PO split — check what we actually invoiced him in October

attest_tagApp

Please confirm — buttons below, expires in 5 min. October was one invoice, £24,000, issued 1 Oct, unpaid. I've written the reply saying it can be split and asking for the two PO numbers. It will be saved as a draft in your Gmail — I don't send.

The reply, drafted with the real number in it.

The reason a reply sits unwritten for five days is usually that answering it needs a number from somewhere else. The thread is read, the invoice is looked up in billing, and the draft is written with the figure in it — then saved as a draft in the asker’s own Gmail, where they open it, change it and press send themselves.

http_request

attest_tagdirect message

Dan

who have I emailed in the last fortnight that never wrote back?

attest_tagApp

Six threads where yours is the last message and nothing came back. Three look worth a nudge — Harrow Freight (12 days, quote), Mei at Northwind (9 days, contract redlines), and the recruiter for the platform role (8 days).

The six mails nobody answered.

The follow-up that never happens is the one nobody has a list for. Sent mail from the last fortnight, threads where the last message is the asker’s own, minus the ones that never wanted an answer — a list short enough to act on before the end of the day.

http_request
run_js

attest_tagdirect message

Mei

every weekday at 7:30 send me anything that landed overnight from a customer, and nothing else

attest_tagApp

Routine created — weekdays 07:30, your timezone. It reads mail since 18:00 the previous working day, keeps what is from an address outside the company, and DMs you one list. Quiet when there is nothing, rather than a message saying there is nothing.

The overnight mail, at half past seven, and nothing else.

A digest is only useful if it is allowed to be empty. This one reads the mail that arrived since the end of the previous working day, keeps what came from outside the company, and says nothing at all on a quiet morning — which is what stops it becoming another notification people learn to scroll past.

create_routine
http_request

Finance & ops

The month-end chores, done before the meeting.

The billing key is a read-only restricted key and nothing more, so the whole group is safe to hand to whoever is asking. Every figure is worked in the sandbox rather than recalled, and the one thing here that changes anything — a task on a board — is a card someone presses.

financethread

Priya

@attest_tag what's in Friday's payout? it's £41,204.18 and I can't make it tie

attest_tagApp

Eleven invoices, £42,980.00 gross, less £1,775.82 in fees, is £41,204.18 — it ties exactly. The reason it looked wrong is that two October invoices are in there and one September one is not: INV-0398 was paid on the 2nd and landed in the previous payout.

The payout, tied to the invoices in it.

An hour with a spreadsheet, answered in two minutes: the paid invoices in the window, the fees, and the sum — worked in the sandbox, not recalled. The useful part is not the total but the sentence explaining why it looked wrong, which is the thing a reconciliation is actually for.

http_request
run_js

financethread

Dan

@attest_tag anyone about to churn on a failed card?

attest_tagApp

Four subscriptions have a failed charge in the last week; two are on their final retry. Northwind (£1,000/mo, retry Thursday, owner Dan) and Ledgerly (£240/mo, retry tomorrow, owner Priya) are the ones worth a call today.

The customers about to leave over a card, not a decision.

Involuntary churn is the kind nobody chose, and it is invisible until the subscription is gone. Failed charges in the last week, joined to the subscription behind each one and the account owner in the CRM, so the list is short and each line has a name against it.

http_request
hubspot_search
run_js

financethread

Priya

@attest_tag on the 1st of every month at 9, post last month's revenue, new customers and churn here — and attach the workings

attest_tagApp

Routine created — 1st of the month, 09:00, this channel. It pulls the month's invoices and subscriptions, works the three figures in the sandbox, posts them, and attaches the spreadsheet it worked them from so anyone can check the arithmetic.

The monthly numbers, with the workings attached.

The monthly figures are a morning of somebody’s life, every month, forever. This is that morning as a cron line — and it attaches the spreadsheet it did the arithmetic in, because a number in a Slack message that nobody can check is a number nobody ends up trusting.

create_routine
http_request
run_js
create_artifact

opsthread

Mei

@attest_tag what's waiting on me and what's waiting on someone else?

attest_tagApp

Three are waiting on you: the Northwind PO (9 days), the contractor renewal (4 days), and the security questionnaire sign-off. Seven are waiting on other people — Dan has four of them, two of those older than a fortnight.

What is waiting on you, and who is sitting on the rest.

Every board has a column that is really a queue of other people, and nobody reads it as one. The open items are split into the ones whose next move belongs to the person asking and the ones that do not, and the second list is grouped by whose desk it is sitting on.

clickup_search_tasks
run_js

Bring the channel your alerts land in.

Sign up, add it to one monitoring channel and one repository, and watch it triage the next alert — and stop at the first write. Or run the same binary on your own infrastructure.

Try it now Deploy it yourself

How connections work