Krahnie

Another easter egg yuker score example(may have misspelled eucher)
Example check how much time I've logged against a client conversation
One of our many easter eggs (short circuited in the Gateway script so costs $0 in AI tokens)
Agent First Pass confirmation replies and status updates
Example card being created from a Slack message
Krahnie leaderboard showing off who on the team is using Krahnie(taken when Krahnie was first rolled out to the team)
Example of us having fun with Krahnie asking about our logged time
Home Page

Note: Krahnie is an ongoing build we started before the hackathon and use internally at Krahnborn. The goal from day one has been a focused one: how do we make production-ready conversational workflows for our Salesforce delivery team — not a chat toy, but something our consultants actually run every day. Krahnie is the standalone successor to an internal Slack plugin we'd already been running inside our Hermes bot; the Slack Agent Builder Challenge is what pushed us to harden it into a real, demoable agent.

Inspiration

Salesforce consulting delivery lives in two worlds that don't talk to each other. There's the messy human conversation in Slack — the asks, the blockers, the "wait, what did we decide?", the client context — and there's the rigid Salesforce schema — cards, work logs, status, hours, SLAs. Every day our team pays a context tax moving between them: logging time in a form, updating a card in a UI, writing a status report by hand, digging back through threads to remember what was actually agreed.

We didn't want another assistant that answers questions. We wanted to break the barrier to entry on our own delivery work — so anyone on the team could create a card, log time, kick off a coding agent, or ship a client doc just by talking in Slack, with no SOQL, no forms, and no learning curve. And critically, we wanted it to be production-ready and cheap enough to run all the time, not a demo that falls over the moment a real request comes in.

What it does

Krahnie is a conversation-first Slack agent that runs our Salesforce delivery practice from inside Slack.

Cards & work, conversationally — create, edit, close, and reassign cards from plain English; log and correct time by just saying it, with the agent inferring the card you meant and showing a picker only when it's genuinely stuck.
Conversation intelligence (Real-Time Search) — "what did we decide about X?" returns a grounded answer with cited source threads, searched over what the requesting user can actually see.
Agent handoff → real pull requests — hand a card to a coding agent from the App Home; Krahnie assembles an RTS-grounded task brief, runs an autonomous first pass in an isolated sandbox worktree, and opens a draft PR. Give feedback in the thread and it resumes the same branch and updates the PR — it knows a revision from new work.
Delivery docs — on card close, one click produces a client-ready doc grounded on the PR diff, published to Krahnborn's Internal Notion Delivery Documentation database.
PM / delivery-lead reporting — outstanding/completed work, hours-by-person, utilization, velocity, SLA, client KPIs, a portfolio health board, and a client-facing status report with a written narrative.
Slack-native everywhere — Assistant/Agent pane with suggested prompts, an App Home dashboard, slash commands, modals, message shortcuts, and voice clips (transcribed locally).
Proactive ("works at night") — a Monday morning digest, durable reminders, a daily log-time nudge, and nightly sweeps that triage the week before you wake up.
Cross-org ticket sync — two-way sync between client Salesforce orgs and our internal cards, with no middleware or Apex in the client org.

It uses all three of the hackathon's required technologies: Slack AI capabilities, an MCP server (its ~30 workflow tools are MCP tools; it also consumes the Notion and Lucid MCP servers), and the Real-Time Search API.

How we built it

A provider-agnostic agent loop built on Pydantic-AI. A fast Claude Haiku model is the orchestrator — built-in tools stripped, ~3K-token context, prompt caching, history trimming, per-turn cost accounting. A stronger Claude Sonnet writes only the summaries and enrichment. The core principle: the model is the router/summarizer/judgment layer, not the whole app.
~30 hardened, in-process tools (krahnie/tools/*) that do the real work — SOQL/DML against Salesforce REST, RTS search, git/PR orchestration, doc generation. They're defined as MCP tools, so they also run under an MCP server.
A Socket Mode Slack gateway (Bolt) — no inbound HTTP — that fast-acks, drives all the Block Kit interactivity, and captures the per-turn RTS action_token into a request context.
Real-Time Search via assistant.search.context, authorized by that user token, grounding answers, card summaries, and handoff briefs. We even cross-ground RTS results with live Salesforce data (sffusion, #27) and extended it to private channels (#26).
The coding-agent pipeline — a metadata-tracking → PR pipeline, plus an autonomous Codex first pass that runs in isolated per-run git worktrees (#122, #123) against sandbox-pinned repos, draft-PR-only, with a hard timeout and a prod/protected-org denylist.
Artifact generation over MCP — Mermaid + Lucid diagrams and Notion publishing (#30, #37–#39, #117, #132–#137), so delivery docs and architecture diagrams are generated, not hand-made.
A deterministic test suite — the consequential logic (status crosswalk, ext-id dedup, loop guard, sync watermark, field mapping) is unit-tested with no network, no Salesforce, no LLM (Salesforce I/O is faked), with a pre-push hook enforcing it (#25, #51).
Runs as a systemd service — a single Python process on our internal server, live in our workspace.

Across roughly a month this became 300+ commits and ~137 merged PRs — shipped in small, reviewed increments.

Challenges we ran into

Keeping the agent cheap and reliable at the same time. The whole "cheap intelligence over hardened workflows" architecture exists because generalized agents burn tokens rediscovering everything. Getting Haiku to reliably route to the right tool (and act instead of interrogating the user) took real prompt discipline and a lot of feedback-driven tuning (#63, #65, and a long line of internal feedback fixes).
A complicated Haiku 400 error. History truncation was orphaning a tool_use/tool_result pair mid-conversation and hard-failing the model. Fixing the trimmer to keep tool pairs intact (#46) was one of those bugs that only shows up under real, long conversations.
Real-Time Search token survival. Migrating to Slack's new agent_view experience broke where the action_token arrives — and without it, RTS silently returns nothing. Restoring reliable token pickup across DMs and the agent pane took several passes (#96, #103, #108, #109).
Safe concurrent coding agents. Two first passes running at once clobbered each other's git state. We moved to per-run worktrees and detached the main clone's HEAD so stale checkouts can't block a run (#122, #123), plus timeout salvage so a slow run degrades gracefully instead of spiraling (#121).
Making the review loop understand "this is a revision." Getting follow-up feedback to route back to the existing handoff and resume the branch — instead of spawning new work or dumping a card list — was subtle routing work (#127–#129, #138).
Delivery docs that survive PDF. Deterministic templates, no truncation, PDF-safe framing (#132) so a client-facing artifact actually looks client-facing.

Accomplishments that we're proud of

It closes the whole loop — from a plain-English Slack message to a merged pull request to a delivered client doc, grounded in the actual conversation the entire way.
We use all three required technologies meaningfully, not as checkboxes — RTS grounds real work, MCP is both how we expose tools and how we generate artifacts, and Slack AI surfaces carry the whole experience.
It's genuinely production-ready. A deterministic test suite, a pre-push gate, dry-run/failure hardening for the demo, and a running systemd service — this is software our team actually depends on.
Feedback-driven from the start. Krahnie captures its own feature requests and bugs as Krahnie_Feedback__c records, and a huge share of our PRs are traceable straight back to those FB-000xx items — the tool helped build itself.
Velocity with discipline — 300+ commits and ~137 reviewed PRs in about a month, shipped in small increments.

What we learned

Encoded workflow beats general reasoning — for a known lane, giving the model a menu of hardened tools is cheaper, faster, and far more reliable than asking it to invent the workflow each time.
Grounding is the multiplier. The moment card summaries and agent briefs started pulling from real Slack threads via Real-Time Search, the output stopped being generic and started being right.
Act, don't ask. The best conversational UX infers and shows a confirm/picker, rather than interrogating the user in prose. Most of our UX polish was removing questions.
MCP is a two-way street — being both an MCP server (our tools) and an MCP client (Notion, Lucid) is what lets a Slack agent produce real enterprise artifacts.

What's next for Krahnie

Deeper structured memory — expanding the Decision and Risk registers (#28, #29) so committed directions and risks captured in Slack become durable, queryable Salesforce records, not just thread history.
More autonomous agent scope — growing the coding agent beyond a conservative first pass toward larger, verified changes, with stronger self-review before it asks a human.
Broader cross-org ticket sync — generalizing the client-org sync (#24, #54) beyond our current setups.
Wider rollout — more of our delivery team, more clients, and a path toward packaging Krahnie so other Salesforce practices can run production conversational workflows too.