Speakeasy

150,000 companies run their business on Salesforce and pay consultants $214 billion a year to keep it working. Speakeasy is going to eat that.

Comment

Inspiration

Salesforce needs constant human administration, and not only when something's on fire. New fields get configured, new automations get built when a process changes, integrations get wired up, and yes, some things break. I ran a Salesforce consultancy for a decade doing all of that by hand. Four months ago I started building Speakeasy to find out whether an agent could do the whole job, not just the half of it where something's already broken.

What it does

Speakeasy is a general-purpose agent that administers Salesforce orgs. Send it a request, any request, by email, Slack, or through the app itself, and it investigates the live org, forms a plan, and executes it once a human approves. That covers the actual range of what an admin's job is: build something new from a request that starts as a sentence, reconfigure something that no longer fits how the business runs, or root-cause something that's quietly broken.

For this event I picked two problems specifically because they sit at opposite ends of that range:

  • A build from nothing. No existing bug, no prior code. Just a request, letting a user create a calendar event with multiple attendees from an Account, and it designs, writes, and deploys a Lightning Web Component and its Apex controller from scratch, live.
  • A root-cause investigation across two systems. A backlog of Salesforce records with nothing visibly wrong on the Salesforce side. The real cause lives in a worker service running elsewhere that silently stopped processing its queue. It has to read logs from both systems and connect them.

Those aren't two versions of the same trick. One is pure creation, the other is pure diagnosis, and it's the same investigation loop doing both.

How I built it

Node, Express, and TypeScript on the backend, MongoDB, Redis and Bull for queues, a React and Vite frontend with real-time updates over sockets. The agent runs on Anthropic's Claude Agent SDK with persistent, checkpointed sessions, so a long investigation can be paused, rewound, or resumed instead of restarted. I tier models by task to keep even a deep investigation cheap. It reaches Salesforce through the REST, Tooling, and Metadata APIs plus the CLI for non-destructive scratch-org testing, the same access a human admin has, nothing more. None of this is templated to "find a bug, write a patch." The agent forms its own plan for whatever the request actually turns out to be, which is what let us point the same system at a blank-page build and a two-system investigation without writing two different products.

Challenges I ran into

The harder problem wasn't either individual demo, it was making sure one agent could do both without us hard-coding "this is a bug" versus "this is a build" anywhere in the system. Building the "before" state for the diagnosis demo surfaced its own real platform quirks: two timezone-handling functions that look interchangeable but aren't, a tab deploy that failed on an invalid theme value, a field name that quietly collided with a reserved one. Different scale of problem, same lesson: the platform has edges everywhere, and the agent has to know about all of them, whether it's building something new or fixing something old.

Accomplishments that I'm proud of

I'm proud that the same agent, same code path, handles a blank-page build and a needle-in-two-haystacks investigation with nothing hackathon-specific glued on for either. It's not a support bot that also happens to write code, and it's not a code generator that only works from a clean slate. It's one general loop, and it's been running that way against a real production org for months.

What I learned

The investigation loop that scopes a brand-new build is the same one that finds a root cause buried in someone else's mess. I didn't build two products and stitch them together. Getting that generalization right mattered more than either individual demo.

What's next for Speakeasy

More categories of admin work beyond Apex, LWC, and Flow, and deeper autonomy tiers so a trusted user can let low-risk changes, whether they're new builds or fixes, ship without waiting on a human at all.

Share this project:

Updates