Cortex's mission is to make every software organization, especially in the enterprise, operationally excellent. Cortex tracks standards and best practices for engineering teams and helps them reach gold status.
Cortex recently launched Engrams, an open source, self-hosted platform for running coding agents in the cloud. It works like Claude Code in a browser. Each session gets its own dedicated micro VM, and any agent harness (e.g., Claude Code, Codex) can plug in through an open protocol, and model routers let teams use any model. Because sessions aren't tied to one developer's laptop, teams can build automations around them. That's where DBOS comes in.
Cortex sees the "software factory" not as code that magically ships itself to production, but as a team's existing SDLC with AI added at each step: writing code, reviewing PRs, flipping feature flags, and so on. Even the smallest factory, shipping one bug fix, is a workflow: a ticket comes in, code gets written, a PR goes up, reviews loop for days, then the change merges, deploys, and the ticket closes. It's a defined sequence of steps, idle for long stretches, moved along by triggers and handoffs.
"Durable workflows really are the primitive of what a software factory is. It's long-running and idle most of the time." — Nikhil Unni, Co-founder and Chief Architect, Cortex
Engrams runs two products on DBOS today:
Automated PR review. A GitHub webhook fires when a pull request opens or a new commit lands. One agent clones the repo and checks it for bugs and security issues, then hands its findings to an independent agent in a fresh micro VM that verifies each claim. The result is posted as a comment on the PR.
Coding in Slack. Mentioning @engrams in a Slack thread starts a new cloud coding session, and teammates can chime in for a multiplayer experience. The workflow relays the conversation between Slack and the agent session.
Cortex has broken these workflows into reusable building blocks, including cron and webhook triggers, filter, branch, loop, and join controls, sandboxed JavaScript for complex logic, and low-cost decision models, so users can assemble their own factories.
A software factory has to survive the reality of production while doing work that can't be undone:
Every run must resume where it left off. A factory needs to survive deployments, restarts, and crashes and pick up exactly where it stopped, even when a run has been waiting days for a code review.
Side effects can't happen twice. Agents clone repos, run shell commands, send prompts, and post comments. Running one of those twice can mean duplicate reviews, wasted compute, or worse. Cortex learned this firsthand when a micro VM was torn down mid-way through a git clone during a PR review.
Idle shouldn't mean expensive. Users should be able to return to a Slack thread from a year ago and pick up the same session. Keeping compute open for that long isn't viable, so sessions need to park cheaply and wake instantly.
User-defined automations. Because users design and edit their own automations, workflows had to be defined by data rather than code, and changing an automation couldn't break runs already in flight.
Cortex chose DBOS as the workflow engine that powers Engrams. Here's what mattered:
Open source. As an open source project, Engrams needed an open source foundation. DBOS Transact is free and open source.
A simple deployment model. Engrams' orchestrator is written in TypeScript and runs on Bun with Postgres already in place. Adding DBOS meant adding a schema to the existing database, with no new service to operate. Cortex had also used DBOS in a recent product launch, so the team was already comfortable with it.
"DBOS is extremely simple. All you need is Postgres, and that's what we already had. You don't need an extra service to operate or a Cassandra cluster." — Nikhil Unni
One data-defined workflow. Every user automation runs as a single automation run workflow, defined by data rather than code. Users can change their automations without conflicting with earlier versions.
Park and rehydrate. Nothing is held open. When a session goes idle, Engrams tears down the micro VM and stores its state in blob storage, leaving the workflow parked in Postgres. Webhooks, session events, tool calls, or operator actions wake it, and the session rehydrates in seconds. A run started a year ago costs only its stored data.
Effectively-once side effects. DBOS provides at-least-once execution and deduplicates webhook and cron triggers, including duplicate GitHub deliveries. Cortex extended that idempotency into the VM itself with a durable on-disk journal keyed by operation ID, so a restarted workflow reattaches to an in-progress command instead of rerunning it. Prompts sent to agents are deduplicated the same way.
Engrams now runs automated PR reviews and Slack-based coding sessions as durable DBOS workflows. Runs survive deployments and crashes, idle sessions cost almost nothing, and every automation produces effectively-once side effects. The same building blocks are now available for teams to assemble their own software factories.
"DBOS guarantees at-least-once delivery, we ensure idempotency on everything we control, and so we get effectively-once side effects for every automation. Engrams just works because we can lean on DBOS for those properties." — Nikhil Unni