Moving fast without compromising reliability

As we continue to onboard health systems with 10,000+ users, maintaining reliability becomes increasingly complex. More customers, more workflows, and more infrastructure create more things to monitor and maintain. Too often, engineering teams respond by spending more time keeping the lights on and less time innovating.

We're determined to build differently at Vitalize. Our mission is to build the operating system for hospitals, and the thousands of clinicians and managers who rely on us deserve both continuous innovation and dependable software. Every interaction on our platform matters, and we believe AI-native infrastructure can help us maintain that standard as we scale, while freeing engineers to focus on improving the product.

Today, we're bringing Skippy in-house and welcoming its founder, Sid Premkumar, to lead our Platform team. Skippy is an AI agent that monitors our infrastructure, investigates issues, and safely automates certain fixes. But what makes it different is its deep understanding of Vitalize: our architecture, our known issues, and the unique operational patterns of the hospitals we serve.

We believe this is where AI infrastructure is heading: purpose-built agents with deep knowledge of the systems they operate, rather than generic tools designed for everyone.

Why AI changes the equation

There's a fundamental challenge in scaling software infrastructure: as systems grow more complex, the work required to operate them grows too. More services to monitor, more alerts to investigate, more incidents to diagnose. Traditionally, companies have addressed this by growing their infrastructure teams and investing in increasingly sophisticated monitoring tools.

AI gives us another approach. Instead of simply telling engineers when something goes wrong, agents can investigate issues, understand their context, and increasingly take action themselves. This allows engineers to spend less time on repetitive operational work and more time improving the systems themselves.

But we think the most important innovation isn't just adding AI to monitoring tools. It's building agents that deeply understand the specific environments they operate in.

Horizontal infrastructure tools are excellent at understanding common patterns across thousands of companies. But the decisions that matter most often require context unique to one organization: its architecture, known issues, operational history, and customer workflows.

Consider self-scheduling day at Vitalize. At 7am, thousands of clinicians can log in simultaneously to submit their shift preferences. To a generic monitoring system, that sudden traffic surge might look like an emergency. To an agent that understands Vitalize, it's expected behavior. The important question isn't whether traffic increased, but whether that increase is actually causing problems.

We believe effective AI infrastructure agents need three things:

Context: Deep knowledge of the company's architecture, historical incidents, known issues, and normal operational patterns.

Tools: Secure, scoped access to the systems they operate, allowing them to investigate problems and take approved actions.

Feedback: The ability to learn from engineers' corrections and decisions so their judgment improves over time.

The frontier models powering these agents will continue improving and becoming more accessible. The real differentiation comes from how deeply they're integrated into the systems and organizations they serve.

Our bet is that a narrow agent with deep context can outperform a broad agent with shallow context on the operational problems that matter most.

Skippy in action - a production issue our customers never noticed

Payroll Monday is one of the busiest mornings on Vitalize. Managers across our health systems review weeks of scheduling data at once, creating predictable spikes in infrastructure load. As we scale to more hospitals and clinicians, those peaks become increasingly demanding. It's exactly when our customers need us most that reliability matters most.

Early one Monday, a critical memory alert fired on one of our core backend services. One of nine identical servers had nearly tripled its memory usage over 90 minutes, while the others remained stable. The affected server supported two of our largest health systems and was processing more than ten times its normal scheduling-data volume.

Normally, an engineer would need to investigate the alert, compare servers, inspect logs, and trace the source. But Skippy already understood our infrastructure and the unique traffic patterns of our customers. It recognized that this wasn't simply a normal payroll Monday surge, identified the abnormal server, and traced the issue to the scheduling-data loading code.

Within 10 minutes, Skippy followed an approved runbook to restart the service, paged our on-call engineer, and shared its root-cause diagnosis alongside a proposed permanent fix. Customers never experienced a slowdown, and our engineers shipped the permanent fix the following morning.

1,817 alerts. 35 pages.

The Monday morning incident wasn't an exception. It's an example of how Skippy operates across our infrastructure every day.

As we grow, we're deliberately monitoring more of our platform, not less. We'd rather catch an issue affecting a single clinician than wait until it becomes a system-wide outage. But more comprehensive monitoring traditionally means more alerts, more interruptions, and more engineering time spent investigating problems that don't always require action.

Over the last 35 days, our infrastructure generated 1,817 alerts. Only 35 resulted in pages to our on-call engineers. Skippy sorts alerts into three categories:

2% — Page an engineer immediately. Issues that need human intervention, accompanied by a summary of Skippy's investigation.

42% — Review later. Issues worth investigating, but not urgently. These are routed to Slack, including 324 overnight alerts that didn't require waking an engineer.

54% — No further intervention needed. Known issues, duplicate alerts, transient failures, and systems that have already recovered.

The system's judgment is grounded in Vitalize-specific context. Over those same 35 days:

103 alerts were recognized as known issues, informed by our own engineering history.

217 alerts were deprioritized because the affected service had already recovered.

121 alerts were identified as normal fluctuations within expected operating ranges.

470 errors were grouped into issues we were already tracking, rather than treated as separate incidents.

We can now maintain comprehensive visibility into our infrastructure without overwhelming engineers with noise. That's the leverage we're building toward: infrastructure that becomes more intelligent as we scale, without requiring operational overhead to grow at the same rate.

Why we're bringing Sid and Skippy in-house

We could have built a system like Skippy ourselves. But doing so would have required hiring a team, building an internal agent platform, and spending significant engineering cycles solving problems that Skippy was already addressing.

Skippy wasn't a prototype or a pitch deck. It was a working product, already integrated with Vitalize's infrastructure, investigating our alerts, and demonstrating its value every day. Bringing Skippy in-house allows us to accelerate that progress rather than start from scratch. More importantly, we're bringing in Sid, the founder who built it and developed a deep understanding of our systems along the way.

We believe exceptional engineers equipped with AI-native tools can operate with a fundamentally different level of leverage. Sid will lead our Platform team, helping us build infrastructure that's increasingly automated, deeply integrated, and designed around the unique demands of our customers.

What comes next

Skippy is no longer being developed as a general-purpose product. Its mission is now singular: helping us build and operate the most reliable infrastructure possible for the health systems that depend on Vitalize.

We're focused on three areas:

Increasing autonomy, carefully. Today, Skippy primarily investigates and recommends. It takes action autonomously only where our runbooks explicitly permit it. We'll expand those capabilities gradually, starting with well-understood, low-risk remediations.

Building a foundation for future agents. Skippy has become a central, audited gateway through which our AI tools can securely interact with our systems. We'll build on that foundation as we introduce additional agents across our engineering workflows.

Making every incident a learning opportunity. The context, decisions, and feedback Skippy accumulates should make it more effective over time. We're investing in systems that retain operational knowledge and turn it into better decisions, rather than repeatedly solving the same problems.

The broader ambition goes beyond incident response. We believe AI will fundamentally change how software companies build and operate infrastructure. Small, exceptional engineering teams will be able to manage increasingly complex systems, automate work that previously required constant human attention, and spend more of their time building what comes next.

For Vitalize, that means continuing to innovate at the pace our mission demands without compromising the reliability our customers deserve.