Under the hood: what makes an Organizational Agent possible

Harpreet showed what an Organizational Agent looks like: a Spec anyone can read, a Dry Run you can send to your manager, credentials that belong to the company, and a Run record for every execution. This post is the view from underneath. Not the full blueprint, but enough to see why those things hold up. Read Harpreet's blog here.

There is a simple way to think about the JoyStream platform. The AI model does the thinking. Everything we build around it exists to keep the result something a team can own, hand over, and trust.

That split shapes the whole architecture. The model is the part that gets better every quarter without us, so we keep our layer around it thin and swappable. The parts that never improve on their own — who authorized what, which version ran, what happened at 6:03pm on Tuesday, whether agents are running securely, whether an agent can be rolled back when it goes wrong — are the concerns organizations and their teams care about.

Here's what the JoyStream platform looks like underneath:

Five layers, and a ledger that runs alongside all of them. A conversation becomes a definition. The definition is compiled into a locked build. The build is deployed into a workspace, where it picks up that organization's credentials and schedule. Running it creates a record, then the agent reasons through the steps, and every action on the outside world passes through one checkpoint and one gateway. What comes back is the record, filled in.

A quick tour of each.

1. Describe the work: the builder is an agent

You don't build an agent on a canvas. You talk to Joyvis, our builder, and Joyvis is itself an agent. It asks what the work is, searches the capability catalog for the pieces that fit, checks whether your organization already has the connections those need, and writes a draft.

The part we engineer isn't the conversation. It's the contract at the end of it.

The builder must produce a definition that fits a defined shape. That's what turns a chat that went well into a specification a colleague can read in a minute.

The Agent Universe catalog speaks the open formats, on purpose

The agents in the Agent Universe catalog aren't a JoyStream-only format. A capability you build on JoyStream is a specification as well, one that aligns with the Agent Plugin format. We build against the specifications the ecosystem is standardizing on.

Agent Skills. A skill is a folder with a SKILL.md file at its root: a short block of metadata (a name, a description of what it does and when to use it) followed by plain instructions, with optional folders for scripts, reference documents, and templates. The format is defined at agentskills.io, and it's the same format Claude, Cursor, and a growing list of tools already read. If your team has written skills for any of those, they load into JoyStream as they are.

Agent Plugins. A plugin is the portable package one level up: a folder with a small plugin.json manifest, a skills/ directory in the Agent Skills format, and an mcp.json that describes the MCP servers the plugin needs. It's an open, vendor-neutral spec at agent-plugins.org, steered by maintainers from Amazon, Cursor, Microsoft, OpenAI, and Vercel. The point of it is that an author packages a capability once and any compatible client can load it.

MCP. The connections underneath, to Slack, GitHub, Monday, and the rest, speak the Model Context Protocol, so a tool built for one MCP client works with our gateway without a rewrite.

Why this matters more than a feature checkbox: creation is the abundant part of this market and we don't need to own it. The value we add starts after the capability exists, when it becomes something an organization can version, share, run, and audit. Standard formats are also what keep the exit door open. A skill or plugin you bring into JoyStream is still a skill or plugin when you take it out, and that is the only honest way to ask a company to depend on you.

2. The agent is a thing you can version

Most platforms store an agent as one editable blob: a prompt and some settings, changed in place. That's why agents are hard to review, hard to hand over, and impossible to trace back from a bad output.

We split it into three parts with three different lifetimes.

Definition — the Spec and the Recipe. Written once, portable, never edited in place. A change creates a new version.

Build — the definition compiled and locked, identified by a fingerprint of its own contents rather than a version number someone typed.

A version number is a claim. A fingerprint is a fact. Every run records the fingerprint it ran, so "which version produced this" has one exact answer.

Deployment — workspace, credentials, schedule. The only part that changes per team.

That last split is what makes handover work. Ownership and accounts feel like properties of the agent, but they're properties of an installation. Keep them inside the artifact and the agent silently carries one person's environment with it.

3. Runtime: one checkpoint, three modes

Starting a run doesn't call anything. It creates a record and queues it. A worker claims it; if the worker dies, the claim expires and another picks it up; submitting the same run twice collapses to one execution. The run exists on its own, independent of whatever process happens to be handling it.

Then the agent engine reasons through the Recipe. Each step already declares how much freedom it needs — a single fixed call, a short reasoning loop over a few tools, or no outside system at all — and what to do if it fails. Those decisions were made and reviewed at build time, not improvised when things go wrong.

Every action toward the outside world passes through one checkpoint. In Dry Run, the checkpoint answers with a realistic stand-in shaped by the real system's contract. In Pilot and Live, it lets the call through. The agent's instructions are identical in all three; it can't tell which mode it's in. That's the reason a Dry Run is evidence and not a demo: it isn't a separate simulator, it's the same path exercising the same structure.

Two details: stand-in answers stay consistent within a run, so something created in step two can be read back in step five. And any result the model produces is checked against the shape the step declared. If it's wrong, the step stops rather than continuing with bad data.

4. Control plane: one front door

Connections are made once, scoped either to the organization and the workspaces in it, or to a specific workspace. The Vault holds the secrets, agents never do. When a step needs to act, token authority lends it access for that one call, scoped to that one action, for that one organization.

All of it goes through the Gateway. There is no second path to Slack or GitHub or Monday. When Joyvis is building an agent, it queries the Gateway live to find the real action and its real input contract, and freezes that into the build. Production doesn't rediscover anything; it runs what was inspected. One door also means one place where access is scoped and one place where every action is attributed, no matter how many integrations sit behind it.

The Run Ledger: the record is the work

As the agent works, it doesn't write a log beside the work. It breaks the job into a graph that defines dependencies and parallelism, and fills it in as it goes, per organization, in versioned storage. The build fingerprint, each step and its outcome, which systems were touched, on whose authority, where a human stepped in. When Harpreet described a Dry Run as an epic with a series of stories, that's not a UI metaphor. It's the storage model. Think of it as a ticketing system for agents, produced from the agent specification.

That's the difference between a system that can tell you what happened and one that can tell you what it logged.

Everything it learns goes into memory

Every run leaves more than a record. The corrections a person made, the step that needed a retry, the data shape that turned out different from what the Dry Run predicted, the approval that was granted and the one that wasn't: all of it is stored in JoyStream's memory system, per organization, alongside the run that produced it.

That memory is what the deployment layer means by "what the agent has learned since it was installed." It stays with the organization's copy of the agent, not with the person who ran it, so the next run starts from what the team already knows. And because it's structured the same way the runs are, it's the raw material for tuning how agents behave in your organization over time, without changing the definition anyone reviewed.

How we build JoyStream: with the same machinery

We don't have a separate way of working for ourselves.

Each JoyStream feature is built by a set of agentic skills that run through the same path described above. A feature starts as a specification. The skills break it into a piece of work and its steps, exactly the way an agent breaks down a job when it runs, and those steps become tickets in the same ledger, with the same dependencies, the same outcomes, and the same record of where a person stepped in. Our engineering backlog and our customers' agent runs are the same kind of object following the same path.

Why it's built this way

Every model-facing component — the builder, the engine, the gateway — sits behind an interface we can replace, and we have replaced each one. The one rule that keeps that safe: a replaceable component never owns the record. Whatever runs, the writes come home to the ledger.

A model can reason. It cannot remember which version it was, borrow the right credentials, know which mode it's running in, or tell you afterward what it did. JoyStream is where those things become true. The model brings the reasoning, the platform is what turns reasoning into work a team can own.

Join the waitlist → · or talk to us directly

— Vivek, CTO, JoyStream.ai