Ryan Cooke is an engineer at WorkOS, where he leads WorkOS Vault, the continuation of JumpWire, the data-security company he co-founded. His work spans enterprise information systems, payments, data protection and AI-assisted engineering, with a recurring concern: giving developers useful access to information while controlling how applications and agents can use it.
From connected information to data protection
Cooke co-founded and led engineering teams at Docurated and Orum. Docurated worked on making information across enterprise repositories accessible. Among the projects Cooke links from his own site is Cluster Emcee, a system for distributing workloads across servers or pods. His financial-technology career included heading U.S. technology at N26 and serving as CTO of Orum, the payments company he co-founded.
He co-founded JumpWire in 2021 to address data-security problems he had encountered in earlier companies; it joined Y Combinator’s Winter 2022 batch. Databases could store and query information, but applications still needed to identify sensitive fields, determine who could access them and control which programs or third parties could process them. JumpWire placed policy-based controls between applications, APIs and databases, operating within customer infrastructure without requiring wholesale data migrations. Those policies could restrict customer information to an appropriate team or give an on-call engineer temporary access.
WorkOS Vault, launched in March 2025, extends this work into encryption and key management. Developers can encrypt and optionally store sensitive objects through an API. Metadata such as tenant identifiers helps determine which encryption keys to use, reducing the bookkeeping developers would otherwise implement themselves. Separate keys for different pieces of information also limit how much data a compromised key can expose.
Cooke’s approach to data security emphasizes what happens after a vulnerability is discovered: engineers must classify information, narrow access and apply protection while allowing people to do their jobs. He argues that priorities should reflect a business’s actual risks, rather than an abstract ideal of perfect security.
Giving agents useful, limited access
Cooke’s AI work applies these access questions to agents. He contributed to Pipes MCP alongside Dan Dorman and Abd Ulhadi Alhallak. The server exposes connected services as agent tools through human-approved, time-limited sessions.
His argument for session-scoped authorization separates a persistent OAuth connection from an agent’s permission to use it. The application can retain the underlying connection, while an agent receives access for the duration of a task. When the session expires, tool access ends; the agent cannot renew its own authorization. This gives applications a way to maintain useful connectivity without granting agents indefinite access.
Building the engineering process into automation
Cooke’s approach to software factories grew from a practical disappointment: WorkOS’s initial agent-in-a-sandbox setup produced results that were difficult to distinguish from engineers using Claude Code on their laptops. The team turned to automating more of the planning and coordination required to deliver a product.
Two complementary parts of that approach are:
Planning and coordination:WorkOS’s TARS system operates through Slack, Linear and GitHub. Ticket-completion webhooks let it pick up newly unblocked work, and engineers can ask it to reassess a project for missing tasks as implementation reveals gaps. A PM agent drafts Hilltop product documents and breaks reviewed work into tickets. These drafts give engineers something to refine, though Cooke notes that agents can propose excessive scope that humans must cut. TARS also takes a first pass at bug reports and customer-support triage.
Shared context and infrastructure: Horizon provides infrastructure orchestration, while an internal MCP gateway connects tools and explains how WorkOS organizes and uses them. For example, descriptions of Snowflake tables guide agents toward data about product usage and customer conversations. The gateway also supports analysis directly from Slack. Cooke recommends this investment because the same tool access and guidance can serve teams beyond the coding factory.
Cooke also describes WorkOS developing its own sandbox infrastructure to gain control over session information and workload placement. A planned organizational memory layer would make knowledge about teams, responsibilities and working practices available across its AI tools.
He judges automation by customer delivery and reliability. Pull-request counts and generated-code percentages can rise without showing that useful features reach customers faster. Defect rates, recovery time and engineers voluntarily choosing the system provide more meaningful feedback about whether the investment helps.
WorkOS’s first sandbox could produce pull requests, but Ryan Cooke found little difference from engineers using coding agents locally. TARS and Horizon extend automation into planning, review, project coordination and context gathering—the work that turns code into a product.
A sandbox can generate code without improving product delivery. WorkOS’s initial experience pushed it toward automating planning and coordination alongside implementation.
Ticket dependencies and completion webhooks let TARS continue a project without a fresh prompt at every handoff; requested reevaluation helps expose missing work.
An internal MCP gateway becomes more useful when it explains where information lives and when to query it. WorkOS reuses that guidance for coding, data analysis and customer analysis.
▶ Watch ↗