The useful thing about a racing yacht is that it refuses to entertain abstractions for very long. Weather is not a chart; it is the force filling the sails. Telemetry is not a dashboard; it is a clue about whether the boat is fast, strained, or in trouble. A forecast becomes a decision, and the decision becomes miles gained or lost. Matthew Gregory began his working life in that compressed loop between signal and consequence.
After studying engineering at the University of Michigan, he went to New Zealand and joined an America's Cup team. He had sailed in college, but the professional version put him inside a floating laboratory. His work mixed navigation, weather analysis, sensors, analytics, and wireless communications. He has compared the setup to the real-time systems behind Formula One: machines moving at speed, specialists watching numbers, everyone trying to understand what the system will do next.
The analogy acquired teeth during the 2008-2009 Volvo Ocean Race. Gregory sailed much of the round-the-world course aboard Black Betty. In the Indian Ocean, the boat suffered a structural failure in its keel system. For a tense stretch, the job was simply to keep it afloat. The crew reached Singapore, but its race was over. Many technology biographies borrow maritime language because “navigation” sounds noble. Gregory earned the metaphor the expensive way.
The weather became a tool
The financial crisis thinned professional sailing, nudging Gregory toward a more conventional technology career. Conventional is doing some work in that sentence. He joined Weather Underground and built a developer API at the moment the iPhone and App Store were creating a sudden appetite for weather inside software. Yahoo, Facebook, Eventbrite, and mobile apps needed forecasts without becoming meteorology companies. Gregory helped package the data so developers could call it.
That move, from bespoke systems aboard boats to a reusable interface, established the pattern. Gregory likes tools. He once traced the preference to a great-grandfather who moved to Detroit, Gregory's hometown, to work as a tool-and-die maker. The family resemblance is philosophical rather than metallic: take expertise that is scarce, shape it into something dependable, and put it within reach of another builder.
At Heroku, later part of Salesforce, the tool was the cloud itself. Developers could push code without becoming server administrators. Gregory worked around product, pricing, and the add-ons marketplace, where applications connected to databases, logging services, and other ingredients. Heroku's genius was theatrical: a great deal happened backstage while the developer enjoyed a very short command.
Then came Microsoft, soon after Satya Nadella became chief executive. Gregory joined work around Azure's embrace of Linux, containers, and open-source partnerships. Cloud applications were being broken into smaller services and scattered across public clouds, private data centers, and vendors. Deployment had become easier. Connection had become stranger. Every useful application was turning into a dinner party where the guests lived in different countries and none should trust a voice merely because it knew the door code.
Trust, packaged for developers
When Gregory met distributed-systems engineer Mrinal Wadhwa around 2018, each had reached the trust problem from a different direction. Wadhwa had wrestled with identity and secure updates in connected city infrastructure. Gregory had watched applications spread across clouds and corporate boundaries. They founded Ockam to make mutual authentication, end-to-end encryption, authorization, routing, and key management available as developer-friendly building blocks.
“I describe Ockam as WhatsApp for Enterprise data-in-motion systems.”Matthew Gregory, Ockam podcast
The WhatsApp comparison was deliberately domestic. People send an encrypted message without opening firewall ports or conducting a ceremony over network topology. Gregory wanted application developers to get a similarly ordinary experience when a process in one private environment needed to speak with a database or service somewhere else. Ockam placed trust at the application layer: cryptographic identities, mutually authenticated channels, short-lived credentials, and policies about who could do what.
It also placed trust at the center of the organization. When asked about company values, Gregory gave one word: trust. He paired it with less lyrical machinery, including objectives and a variation on the RACI responsibility framework. Ockam hired slowly enough that Gregory said it would trade product velocity for the right person. Candidates completed starter projects, which let both sides observe the work rather than conduct a prolonged courtship through polished answers.
A useful abstraction removes low-value infrastructure work while preserving the controls that matter.
Trust showed up in Ockam's cryptography, delegated decisions, public work, and hiring process.
Gregory's founder model is to begin a piece of work, then hand it to someone equipped to improve it.
Industries changed. His fascination with signals, interfaces, and distributed systems did not.
His most memorable management metaphor is giving away Legos. The founder gets a project started, then gives it to a colleague who can build further. The hard part is not assembly; it is releasing the satisfying little click of ownership. Gregory acknowledged that specialists on the team were often better at the work he initiated. The observation is modest, but the mechanism is serious. Good infrastructure and good delegation both depend on clean interfaces.
That approach was reinforced by what Gregory read while making the leap. Around the time he left Microsoft to start Ockam, he was reading Ben Horowitz's The Hard Thing About Hard Things. Gregory said readers tend to recoil from its accounts of company-building or become excited by the difficulty. He belonged to the second camp. Horowitz's later distinction between values, which are believed, and virtues, which are practiced, also gave Gregory language for the operating culture he wanted. Trust could not remain a nice intention. It needed evidence in how the team built, hired, decided, and responded.
Ockam raised a reported $21.4 million, including a $12.5 million Series A in 2022, and grew an Apache-licensed Rust project with contributions from a broad developer community. Its commercial journey was less permanent. The company chapter closed in July 2026, while its code and documentation remained public. Open source makes an unusual afterlife possible: the office can vanish before the artifact does.
The agents inherit the identity problem
By then, Gregory and Wadhwa had already carried the underlying ideas into Autonomy. The new platform addresses software agents that act over long periods, call tools, exchange messages, and scale into large groups. The cast changed from microservices to autonomous processes, but the questions grew familiar. Which agent is speaking? Which system may it reach? Can its actions be attributed? How does a developer move from a lively demonstration on a laptop to an operated product?
Autonomy announced general availability in September 2025. Gregory described a platform where each agent receives cryptographic identity, memory, knowledge, secure connections, and observable infrastructure. The ambition is broad, but the design instinct is old: developers should not need to stitch together dozens of tools merely to run an agentic product at scale.
The fashionable nouns in Gregory's career have changed with suspicious regularity: IoT, cloud native, zero trust, agents. The verbs are steadier. Measure. Connect. Authenticate. Delegate. His work tends to occupy boundaries where one system needs to understand another and where a person needs enough clarity to make a consequential choice.
The people around him recur, too. Gregory met product leader Glenn Gillen at Heroku and later brought him into Ockam. His first conversation with Wadhwa felt, in Gregory's description, like an immediate meeting of minds. The continuity matters because his stated reason for founding a company was not solely the technical gap. He wanted to work every day with people who could challenge and extend the idea. Open-source contributors completed the loop: users could inspect the work, improve it, learn from it, and sometimes join the team.
This explains why the sailor story is more than biography's decorative opening. A navigator is an interface between a world too large to see and a crew that must act now. The instruments compress wind, current, position, and probability. They do not remove the ocean. They make the next move intelligible.
Gregory has spent the years since building variations of that instrument. A weather API let an app ask the sky a question. Heroku let a developer deploy without handling a rack of servers. Ockam let distant applications establish trust without treating network configuration as a personality test. Autonomy now tries to give AI agents the identities and rails required to operate in company systems.
“Probably my biggest job is get stuff started and then give it to someone else.”Matthew Gregory on the founder's role
There is a gentle irony in a builder becoming skilled at disappearance. The better the API, platform, or protocol, the less its user must think about its maker. Gregory seems comfortable with the bargain. His attachment is not to being visible inside the tool. It is to making the tool simple enough that another person can do something difficult.
At sea, the elegance of an instrument is judged by what happens after someone reads it. In software, the feedback arrives with fewer waves but similar honesty. The system connects or it does not. The identity checks out or it does not. The builder can move, or remains stuck in the plumbing. Gregory's career has been an argument for clearing that path, then handing over the pieces.