In the last month I merged 60 pull requests. As CTO, my calendar hasn't let me ship code at that pace in years. Most of these PRs were written by Eddy, our AI agent — between meetings, on my phone, sometimes at 7 AM after the idea hit me the night before.
We built Eddy internally at Headway in the last two months. It's changed how we work as a company.
Why we didn't just buy something
We already had good tools. Claude Code and Cursor, Glean. Each one handled a piece of what we needed. None of them handled the full picture. In healthcare, that gap isn't just annoying — it's a compliance problem. We process insurance claims. We handle protected health information (PHI). If an AI tool isn't HIPAA-compliant, it doesn't matter how good it is, it doesn't make sense to use it.
We could have waited for vendors to solve this. But if you've been paying attention to AI the last eighteen months, you know that "wait and see" is just a polite way of saying "fall behind." So a small team started building Eddy, our internal AI platform.
What Eddy actually is
At its core, Eddy is a platform built on Claude Code's SDK, connected through MCP (Model Context Protocol) to the systems where our work actually lives: Snowflake, Google Workspace, GitHub, Glean, Jira, Sentry, Datadog, and the list keeps growing.
In roughly two months, a small team shipped:
- Cloud coding agents wired into every major system through MCP connectors
- Scheduled agents that run recurring tasks autonomously, daily briefings, weekly reports, anomaly detection
- Slack bot integrations that meet people where they already work
- A sharing layer with a built-in PHI classifier that ensures conversations containing PHI never get shared with unauthorized users
The part that still surprises me: Eddy was largely built with Eddy. Once we had the first version running, we used it to accelerate building the next version. The feedback loop was incredibly fast.
Quick product market fit
The first week I wanted to give beta access to 10 people, and within days we were at 50. Within weeks, with zero rollout campaign, zero mandates, pure word of mouth, the whole company has access.
No adoption playbook. No executive email saying "please use this." People just started using it because it obviously worked for their use case.
What actually changes
The thing that's hard to convey in a blog post is how Eddy changes the shape of your day. It's not "I do the same work 20% faster." It's "I attempt things I never would have attempted."
When the cost of trying something drops this dramatically, people stop rationing their ideas. You stop self-filtering because "that would take too long." You just try it.
"Cloud agents have completely changed my relationship to planning, building, testing, and debugging." — Daniel Thorne, Staff Software Engineer
"I use Eddy to go from alert to resolution in minutes." — Trpti Sanghvi, Data Science Manager
Emergent behaviors
One thing I'm proud of is who adopted Eddy first; it wasn't just engineers.
One of our business development team members built a "Chief of Staff" agent. Every morning, it pulls metrics from Snowflake, scans Slack and Glean for competitive intel, runs causal decomposition on KPIs, and delivers a formatted briefing before he's finished his coffee. He shared it in our internal feedback channel. Within days, other teams were asking for their own version.
A member of our payer partnerships team created a scheduled agent that checks the status of four Salesforce opportunities every week, scrapes Slack for relevant mentions, and delivers a formatted briefing as a DM. The operations team is now targeting 80% weekly Eddy adoption for Q2 — not because anyone mandated it, but because they watched a colleague save hours every week and thought: I want that.
We didn't need an adoption strategy. We needed the tool to be genuinely useful, and we needed to give people the freedom to discover that on their own.
Data context layer
Every table in a data warehouse comes with an implicit question: how do you actually use this correctly? A column named "status" tells you nothing about which values mean "billable," which filters prevent double-counting, or why a particular join will silently inflate your row count. That knowledge used to live in the heads of the people who built the models, scattered across Slack threads, buried in old tickets, or simply undocumented.
Our data team solved this by building a context registry on top of the warehouse. Each entry captures not just what a table contains, but the business rules that govern it: the filters required for accurate analysis, the edge cases to watch for, the definitions that make a metric mean what you think it means. The entries are written to be legible to both humans and Eddy, so anyone can query the data correctly on the first try without tracking down the person who built the model.
Marketing, operations, and clinical teams (i.e. people who've never written a SQL query) are now pulling their own reports, monitoring their own metrics, and answering their own questions. No more waiting in the data team's queue.
Once you have the brain (the model), the connectors (MCP), and the automation layer (scheduled agents), you don't just have a chatbot. You have a single interface that answers questions, does recurring work, and flags problems before anyone asks.
Safety by design
We operate in healthcare. The data we handle is sensitive, the stakes are real, and we take that seriously. So from the start, we built Eddy with the same rigor we apply to any system that touches patient or provider information.
Here's what that looks like in practice:
- Confidence scoring on every data analysis, so users can see when an output needs a closer look
- PHI classification that prevents sensitive conversations from being shared with unauthorized users
- Logging and escalation paths that flag unexpected behavior for review
- Clear operating norms: the team knows that Eddy is a powerful first pass, and that outputs should be verified before they're acted on
This isn't a solved problem; no one in the industry has finished answering these questions. But building in-house means we control the architecture, and we can embed safeguards at every layer rather than bolting them on after the fact.
What's coming
Eddy ships weekly. Some of what's next:
- Live web dev with hot reloading within our cloud agents
- Smarter Slack integration: Eddy reacting to channel events, handling attachments, managing agents from Slack
- Inline citations: every answer linked to its source so you can verify
- Multiplayer conversations: multiple people collaborating in a single Eddy session
- Custom knowledge bases: pin your team's metric definitions so Eddy always uses the right ones
- Service-level accounts: shared agents with machine credentials so scheduled automations don't depend on individual OAuth tokens
Come build this with us
Less than two months ago, Eddy was a prototype. Today it's how two thirds of the company works. Ask me again where we are in a month.
That's the kind of environment where engineers do their best work: real constraints (healthcare, compliance, scale), real users (70,000+ providers, millions of patients), and the push to build things that change how an entire company operates.
If you're the kind of person who'd rather build the tool than wait for the vendor, we're hiring.
