We've been running AI agents at AuthZed that we actually trust. The platform behind them, Open Agent Primitives (OAP), is now open source.
Why we built it
We started where a lot of teams start: personal agents running with one person's credentials, hopefully scoped correctly, inside a sandbox that was hopefully configured correctly. That was good enough to show us agents could be useful.
But we're an authorization company, and we knew there was a better way:
- Access controls could be more granular than whatever a given credential allows
- Actions could be permitted, rather than just contained by a sandbox
- An agent could act on behalf of someone or run independently with an identity of its own
- A team, not just an individual, could collaborate with an agent, and most importantly, the agent would stick to the permissions granted to that team
We distilled our observations and lessons into a set of primitives we think any enterprise needs to build and run agents it can trust with critical actions and data. Then we implemented them as OAP. Since every enterprise has its own infrastructure and requirements, OAP's components plug in through defined interfaces. You can swap in your own sandbox, LLM provider, memory system, and other backends, and the primitives still hold.
We've been running OAP internally for several months, building, deploying, and working with agents on it. Here's one of them.
An agent for our marketing team
Our marketing team asked for a design agent that already knows our brand and can take feedback on a draft. Claude Design does this well: describe a page in chat, get it back in your brand language, then click an element and leave a comment to revise it. We wanted the same workflow for our team, running on our own platform.
So we built our own self-hosted take on Claude Design. It takes a marketing brief, asks about the audience, the key message, and the call to action, then builds an HTML page from our real design system and approved copy. Reviewers open the page, pin notes to the parts they want changed, and our marketing design agent revises it. Every revision is saved and stays accessible.
We didn't write any new platform or agent code for it. The marketing design agent is composed of four components OAP already had:
- An agent definition, with a system prompt that scopes the brief before it designs anything
- A read-only GitHub tool that can only read from the repositories that hold our brand assets
- Two design skills from Anthropic's public skills repository, frontend-design and theme-factory
- OAP's artifact viewer, which gives it a versioned canvas and click-to-comment feedback
Why run your own
Running our own marketing design agent means:
- Our data stays on our infrastructure. Briefs and unreleased messaging never leave our cluster.
- Our choice of model. The agent uses whatever model we configure: Anthropic, OpenAI, or any model available through OpenRouter.
- Our brand and agent skills. We set it up by providing three things at install: a read-only GitHub token, the repositories that hold our brand assets, and which skills to load. Point the same bundle at different repos and it works for a different brand. We can add our own brand-voice skill the same way.
- We can extend it. Slides, prototypes, export to other tools, and handoff to a coding agent can all be added with parts OAP already ships.
What the primitives add
The design agent is built on the primitives, so it inherits what each one enforces. Here's what each primitive provides, and why it lets us trust the agent:
- Agent definition. An agent session runs for each design request, while the design agent itself is defined in a repo where we can iterate on it.
- Authorization. The design agent can only read the repositories we've approved, and any write, or any read from another repository, is refused before it reaches GitHub. That check runs outside the model, so no prompt can talk its way past it, and the agent only sees the material we chose. Feedback is checked the same way: a note can only target an artifact its author is allowed to view, so no one can steer a design they aren't permitted to see.
- Identity and credentials. The GitHub token is read-only, and write actions are not permitted. A reviewer's notes reach the agent attributed to that reviewer. Anything taken from the page itself is treated as data, so text inside a design can't pose as an instruction.
- Safe tools. The GitHub tool runs in a sandbox that can only reach GitHub. Artifacts are rendered inert, so scripts in a model-written page don't run when you open it.
- Channels and continuity. The agent works in a Slack thread or OAP's browser chat, and the conversation stays linked to the design it produced. A colleague can ask to join, and once the owner approves, they can chat and pin notes too. A team can review a design together without anyone getting more access than the owner granted.
- Memory and knowledge. Revisions are immutable, so revision 1 is still there, byte for byte, after revision 2 lands. Each session's transcript is a signed, append-only audit log you can verify offline to see what the agent read and what it was asked to change.
None of these depend on the model following instructions. OAP enforces each constraint deterministically, and none of them is specific to a design agent: every agent on OAP is built on the same primitives.
What we're releasing
- The Agent Primitives: conceptual definitions you can use to evaluate any agent platform, including one you build yourself.
- Open Agent Primitives (OAP): our open source implementation. It ships with working defaults, so anyone can deploy it and start building agents within minutes (assuming you have a spare Kubernetes cluster handy). It includes example agents and tutorials to help you build your own.
Read the definitions, install OAP, and try building your own agent.