Search lore: invoice retries
Invoice retries
Three retries, then manual review. The customer is emailed before review starts.
Who owns billing
Tomás Ruiz owns retry logic; Maya Chen owns customer email templates.
Open source · self-hosted
It answers from what your company already knows, turns decisions into shipped code, and learns from every thread.
Self-host: bun install && bun start
@scout why do invoice retries stop after three attempts? Is that on purpose?
Yes. #billing decided it on June 12: three retries, then the invoice goes to manual review, because a fourth retry was tripping card-issuer fraud flags. Tomás Ruiz made the change. #billing · Jun 12 ↗1
Right. We should email the customer before it hits manual review, though. @scout can you take that?
Opened ENG-4122 and started in my sandbox.
Open a pull request from scout/email-before-review?
A private agent is only as good as the person typing. An agent that works in public gets better with everyone who watches, corrects and builds on it.
Every answer stays in one DM. The next person asks the same question and starts from zero.
Works in public channels only. One person's hard-won answer becomes the next person's starting point, and anyone can step in to correct it.
The whole system on one drawing. Solid lines run today, hatched parts are being built, dashed parts are designed but not built.
Answers from your company's Slack history and cites every claim. When nothing turns up, it says so and doesn't guess. Repos and MCP servers come next.
Writes the change in its own sandbox, runs the tests, and opens a pull request once a person approves it. Next: opening the Linear or GitHub issue from the thread.
Planned: sending and reading email, and new abilities through connections whose credentials the model never holds.
Works in Slack, where your team already talks. Planned: other chat tools, and an app of its own for everything it knows.
Next: saving what it learned after each session. Planned: routines on a schedule, and reviewing what it learned overnight.
Lore is what your company knows, plus what Lorehouse learns while working for it.
Someone mentions the agent in a channel. Everyone can read along and step in.
It searches what your company knows and codes in a sandbox of its own.
What it learned will become a note the next session starts from, linked to its thread.
While nobody is asking, it will merge duplicate notes, correct what went stale and drop what turned out wrong.
Then back to step 1
Lorehouse's own web app. It doesn't replace your chat. A chat surface comes later.
Three retries, then manual review. The customer is emailed before review starts.
Tomás Ruiz owns retry logic; Maya Chen owns customer email templates.
It works in public channels. A DM gets pointed to one, and private channels stay shut.
Every answer links to where it came from. No source, no claim.
Code becomes a pull request only after a person approves it in the thread.
It names people but never @-mentions them, so asking about someone doesn't ping them.
Self-hosted, with its data in plain SQL in your own database.
TypeScript on the June framework, with Firecracker sandboxes. A black-box conformance suite pins its behavior, so any implementation that passes it is interchangeable.
# point it at a public channel
SLACK_SIGNING_SECRET=… SLACK_BOT_TOKEN=xoxb-… \
ANTHROPIC_API_KEY=… AGENT_CHANNELS=C0123456 \
bun start| env | default | what |
|---|---|---|
| AGENT_NAME | scout | The agent's handle in Slack |
| DM_MODE | redirect | Point a DM to a public channel, ignore it, or answer from public knowledge |
| INGEST_BACKFILL_DAYS | 90 | How much channel history it reads on first start |
Pre-alpha. It runs against real Slack, but it isn't ready for your team yet.
Star the repo to watch it come together, or leave your email and we'll tell you when hosted Lorehouse opens.
we build this in the open too.Star on GitHub