Demo A SEV-1, from alert to verified fix, in one thread

AI that answers with sources and acts with approval.

Paploo works in your team chat with your company's tools and data. Everyone sees only what they're allowed to, credentials never reach the model, and it runs in your cloud or on your own servers.

Answers with sourcesEach claim links to the log, deploy or ticket it came from.
Changes need approvalAnything that changes a system waits for a person or a rule you set.
Credentials stay protectedEncrypted at rest and never shown to the model.

# inc-workerSEV-1worker returns 5xx · checkout jobs are failing

MonitoringAPP10:05

Firing5xx rate on worker-prod is 12.4%

SLO 1% · since 10:04 · 1,812 failed jobs

Emily Brooks10:06

@Paploo what is going on? Checkout is backing up.

PaplooAPP10:07

Working on it · 0:01

Read error logs · Kubernetes worker-prod2 s
Read deploy history · deploy #57 at 10:031 s
Compared release 2.13 → 2.14 · MR !4823 s
Checked who is on call · rota1 s

The 10:03 deploy raised queue concurrency from 20 to 80. Since 10:04, 12% of worker requests return 5xx.

Deploy #57 shipped release 2.14 from MR !482, merged at 09:52.
The July incident had the same cause and was fixed by a rollback.
Sam Carter is on call until 18:00.

logs worker-prod · 10:07 deploy #57 · 10:07 MR !482

4 steps · 4 reads · 7 s

Roll back worker to 2.13 Waiting for youApproved

Reverts deploy #57 on worker-prod. Queue concurrency goes back from 80 to 20.

Write · Kubernetes worker-prod · asks before running

Approved by Sam Carter · 10:08

PaplooAPP10:09

Rolling back, then watching the error rate

Rolled back deploy #57 · write, approved38 s
Watching 5xx rate · 3 min under 1%3 min

Verified5xx is back under 1%

0.3% for the 3 minutes after the rollback, and concurrency is 20 again. The postmortem draft is in Work, linked to the July incident.

5xx rate · 10:13 rollback #58 · 10:09 Postmortem draft

Message #inc-worker

Works with SlackGitLabGitHubJiraConfluenceKubernetesSSH hostsAny MCP server

How it works

Ask in chat. Get back work you can check.

1Ask, or let an alert ask

Mention Paploo in any thread, or point an alert at it so it starts before anyone is paged.

2It works with your access

Each request runs in an isolated workspace that can reach only the tools that person is allowed to use.

3You get a verified result

Every claim links to its source. Changes wait for approval. Work is checked before it is marked done.

Why Paploo

Same request. Different outcome.

A generic AI assistant answers from memory and acts as soon as it is asked. Paploo checks its sources, asks before it changes anything, and uses each person's own access.

Generic AI assistantShared bot account

Sam Carteron call

Roll back worker to 2.13.

Done. I rolled back worker to 2.13.

No approval asked
Not verified after the change
No record of who approved it

0/3checks passed

PaplooEach person's own access

Sam Carteron call

Roll back worker to 2.13.

Checked Sam's accessAsked Sam to approveWatched the 5xx rate

This changes production, so I asked first. Sam approved at 10:08. Rolled back, and the 5xx rate has been under 1% for 3 minutes.

Waited for approval
Verified the result
Recorded who asked and who approved

3/3checks passed

Same request, sent to both at the same moment.

After the fix

The fix took eight minutes. The work around it took a week.

Five people touched this incident after the rollback. Passing work between people is easy. Doing it without anyone seeing more than they are allowed to is the hard part, so Paploo checks access at every step.

01 · Mon 10:15Collaboration

One workstream for everyone on the incident

Sam turns the thread into a workstream. Emily, Megan and Dana pick up their parts on one shared page: stages, owners, evidence and the next step. Nobody has to ask for the latest.

Shared page, separate access. Paploo acts with each person's own permissions. Emily sees the customer impact; the prod logs stay with the engineers.

Worker 5xx after deploy #57Mitigated EBSCMH4 here

MitigateSam · done 10:13
Root causeMegan · in progress
Fix forwardDana · Wed
PostmortemEmily · Fri

Next stepdue Tue

Find out why MR !482 passed reviewMegan · 3 records attached

Megan is writing

Outputs3

LivePostmortem draft

SnapshotCustomer update for support

VerifiedRollback evidence, 3 records

Sam turned the thread into a workstream10:15

Emily shared the customer update with support10:21

Megan took Root cause10:24

02 · Mon 18:00Handoff

A handoff the next person can act on

Sam's shift ends. Paploo writes the handoff: what is done, what is open and what to watch, each with its link. Megan picks it up, and Paploo carries on with her access.

The work moves, the access doesn't. Every link is checked again against Megan's permissions. Sam's private notes stay with Sam.

Shift change1 open itemMon 18:00

Sam CarterOn call until 18:00

Handoff · worker 5xx

Rolled back to 2.13, verified 10:13
Open: why MR !482 passed review
Watch: 5xx alert armed at 1%
2 private notes from Sam

Drag the handoff to Megan

Megan HayesOn call from 18:00

Drop here

Checked 4 links again with Megan's access: all 4 open

Left out 2 private notes. They stay with Sam

Paploo picked up the open item for Megan at 18:00

or drag the card

03 · Tue 09:12Company map and context

Context from the whole company, drawn for each person

Megan asks who owns the queue config. Paploo walks the company map from the service to its config, the change that touched it, the team that owns it and the person who fixed it in July.

The map is drawn per person. Switch the viewer and watch it change. What someone can't open, Paploo won't show, name or use in their answer.

Company maparound worker11 records

View as

platform-runtime owns the queue config. Ask Ethan Walsh; he fixed this in July.

1 private

04 · Tue 09:13Answers with sources

Every line has a source, or says it doesn't

The answer comes back with a source on every line. When Paploo can't confirm something, it says so and names what it would check next.

Checked live, with the asker's access. No claim comes from memory alone, and none comes from a record the asker can't open.

# platformTue 09:13

Who owns the queue config, and who can help?

platform-runtime owns the queue config. Dana Miller changed it in MR !482, and Ethan Walsh approved it. Ethan fixed the same problem in July with a rollback. Ethan is on the platform rota until 17:00 today. UnconfirmedWhether 80 came from a load test. The report isn't linked to the MR; I'd check the load-test dashboard next.

CATCatalog · platform-runtimeOwner record · synced 09:00

GLGitLab · MR !482Author and approver · read 09:13

INCIncident memory · Jul 14Fixed by rollback #391

ROTRota · platformEthan Walsh, 09:00 to 17:00

?Load-test reportNot linked from MR !482

4 claims checked1 unconfirmedpoint at a line to see its source

05 · Fri 16:00Lessons and playbooks

Every incident makes the next one easier

The postmortem closes. Paploo turns what went right and wrong into lessons, Emily approves them, and they join the incident playbook. The next alert starts from what this one taught.

Lessons keep their source's access. A lesson from a private channel or a DM is never shared beyond the people who could see it.

Incident playbook6 lessonsupdated Fri 16:00

Check concurrency changes first when 5xx follows a deploy

From the worker incident · approved by Emily · used 2×Platform team

Link the load-test report to MRs that change limits

Waiting for reviewPlatform team

Use the rota, not the channel topic, to find who is on call

From Sam's DM · Sep 30Only Sam

This month: 6 lessons approved · 2 waiting

Started from a lesson: checked concurrency changes first

Reliability

It tells you before it breaks.

Paploo tests its own connections, tokens and budget on a schedule. When something is about to fail, you hear first, with the fix attached.

Expiring tokens are flagged days ahead, not at the moment a run needs them.
Failed steps say what broke and what to do next, in plain words.
Budgets warn before the limit, so work never stops halfway.

Health checks4 of 5 OKLast run 10:00 · next 11:00

GitLab

Read and write · tested 4 min ago

Kubernetes · worker-prod

Read only · tested 4 min ago

Jira

Token expires in 2 days

Expires soonRenew

Monthly budget

$288 of $400 · 72%

Incident first response

Last run 10:05 · 7 s

Security

Credentials never reach the model.

Every action Paploo takes is checked against your policies. A separate proxy adds credentials on the way out, so the model never sees them, and requests reach only the hosts you allow.

Nothing to leak. Credentials are encrypted at rest and never written to prompts, images or logs.
Per-person access. Paploo acts with each user's permissions and nothing more.

Request pathevery request

Policy checkEvery action is checked. Changes need a rule or an approver.

Credential proxyHolds credentials and adds them on the way out.

Network allowlistOnly listed hosts are reachable. The rest are blocked and logged.

Deployment

Your cloud or your servers. Your choice of model.

Run Paploo in your own cloud account or data center on Kubernetes, or on a single server with Docker Compose. Connect the model provider you already use, or models you host yourself.

Any model provider. Anthropic, OpenAI, AWS Bedrock, Google Vertex AI, any OpenAI-compatible API, or your own models on vLLM or Ollama.
Switch without rework. Connections, permissions and playbooks stay the same when the model changes.
Data stays in your network. Self-hosted, what Paploo reads and writes stays inside your infrastructure.

Deployment

Calls go to Anthropic's API. Credentials stay in Paploo's gateway.

Single sign-onOkta, Google or any OIDC provider.

Roles and accessAdmins manage the organization. Members see their own work.

ApprovalsChanges need a rule or an approver.

Audit trailWho asked, what ran and who approved it.

Usage limitsBudgets per person and team, with a warning before the limit.

No training on your dataPaploo doesn't train models on what it reads.

Automations

Set it once. It runs on its own.

Give Paploo a standing job. It runs on a schedule or when something happens, and pings you only when it needs a decision.

AutomationsThis week · 14 runs1 needs you

MonTueWedThuFriSatSun

Incident first responseOn every SEV alert

CI triageOn a failed pipeline

Release checksWeekdays at 09:00

Needs youApprove release 2.15

Dependency reviewMondays at 08:00

Use cases

Built from the same pieces. Pick one to see where it's used.

Incident response

BeforePaged at 2 a.m., then 40 minutes across logs, deploys and chat.

With PaplooCause, rollback and evidence in the thread. The rest of the week runs as one workstream.

Answers with sourcesWorkstreamsHandoffs

On-call handoff

BeforeA rushed message at shift change, and the next person starts cold.

With PaplooDone, open and watch items with links, checked again for the next person's access.

HandoffsWorkstreams

New engineer onboarding

BeforeTwo weeks of asking who owns what, and where it is written down.

With PaplooAsk the company map. Each answer links to its record and stays within your access.

Company mapAnswers with sources

Customer escalation

BeforeSupport waits on engineering for a status they can share.

With PaplooSupport and engineering share one workstream. Support gets the customer update, not the logs.

WorkstreamsAnswers with sourcesCompany map

Code review

BeforeMerge requests wait a day for a first look.

With PaplooA first review in minutes. Comments cite the line, the rule and past lessons.

Answers with sourcesPlaybooks

Release checks

BeforeA checklist someone forgets on Friday afternoon.

With PaplooChecks run at 09:00 and learn from what the last release missed.

AutomationsPlaybooks

FAQ

Common questions

What is Paploo?

Paploo is an AI assistant for teams, made by Spadina Labs. It works in your team chat with your company's tools and data, answers with sources, and asks for approval before it changes anything.

How is Paploo different from a general AI chat assistant?

Paploo reads your own systems at the moment you ask and links every claim to its source. It says what it can't confirm, uses each person's own access instead of a shared bot account, and waits for approval before any change.

Can Paploo run on our own infrastructure?

Yes. Run it in your own cloud account or data center on Kubernetes with Helm, or on a single server with Docker Compose. Self-hosted, what Paploo reads and writes stays inside your network.

Which AI models does Paploo work with?

Anthropic, OpenAI, AWS Bedrock, Google Vertex AI, any OpenAI-compatible API, or your own models on vLLM or Ollama. You can switch providers without changing connections, permissions or playbooks.

How does Paploo handle permissions and credentials?

Paploo acts with each person's own permissions. Credentials are encrypted at rest and added by a separate proxy on the way out, so the model never sees them. Requests reach only the hosts you allow, and every action is recorded.

Which tools does Paploo connect to?

Slack, GitLab, GitHub, Jira, Confluence, Kubernetes, SSH hosts and any MCP server.

Does Paploo train AI models on our data?

No. Paploo doesn't train models on what it reads.

How do we get access?

Paploo is in early access. Book a pilot and we'll set it up with your tools.

Hand off the work.
Keep the keys.

We are opening Paploo to a small group of teams. Book a pilot and we will set it up with your tools.

Or message the founders on LinkedInDagm Fekadu Ilya Dashkovsky