The Orion family is my answer to that: small, focused libraries for those problems, built to one quality bar and published on NuGet.

Today it is 24 libraries in 89 packages, downloaded more than 350,000 times. This post is about why they exist, what holds them together, and what each one is for.

Primitives, not a framework​

Every Orion library solves one problem and stands on its own. You add OrionLock because you need a lock, not because you signed up for a platform. There is no deep dependency web between them; pick only what you need.

That also means saying no. OrionPatch is a transactional outbox, and its documentation says plainly that sagas are out of scope: if you need a process manager, reach for MassTransit or Wolverine instead. A library that knows where it stops is easier to trust than one that wants to be everything.

What holds the family together​

Building the libraries one after another, I noticed five things being implemented again and again, and drifting apart each time:

• calling observers safely, so an observability outage can never break the code that does the real work;
• OpenTelemetry naming, so every library's traces and metrics look alike on a dashboard;
• a clock that tests can control;
• the shape of options and DI registration;
• the vocabulary for errors.

They now live once, in Orion.Abstractions. Its surface is frozen at 1.0: every contract stays source- and binary-compatible across the whole 1.x line, so one library can't break under a sibling's upgrade. The rules that go with it are written down and apply to every package in the family.

Two libraries grew out of that spine. OrionClock is a TimeProvider, so it drops into any .NET API that takes one, and it lets a test move time forward instead of waiting. OrionResult gives expected failures a shape: a zero-allocation Result<T>, an Option<T>, and a structured Error with a code, a kind and field errors.

What is in the family​

Input and the domain

• OrionGuard: validation, guard clauses and DDD primitives, with integrations for ASP.NET Core, MediatR, Blazor, gRPC, SignalR and OpenTelemetry, source generators, and messages in 14 languages. The most used of the family.
• OrionKey: strongly-typed IDs from one attribute, with equality, EF Core and JSON converters generated for you.

Data

• OrionAudit: an automatic EF Core audit trail with JSON Patch diffs, and time travel to rebuild an entity as it was at any moment.
• OrionVault: column-level encryption at rest for EF Core: AES-256-GCM, key rotation, and a blind index for searching encrypted values.
• OrionPage: keyset pagination that stays fast on page 10,000, because OFFSET is a table scan.

Messaging and consistency

• OrionPatch and OrionInbox: the two halves of reliable messaging. Enqueue inside the same SaveChanges transaction and dispatch at least once; on the other side, apply each message's effect exactly once.
• OrionSaga: in-process saga orchestration; when a step fails, the completed steps are compensated.
• OrionRelay: outbound webhooks, signed with HMAC-SHA256, retried with backoff and jitter.

Coordination

• OrionLock: distributed locks with lease renewal and fencing tokens, over Redis, Postgres, SQL Server or EF Core.
• OrionBeacon: leader election, so exactly one instance runs the job that must run once.

HTTP and APIs

• OrionOnce: idempotency keys, so a retried request gets the stored response instead of running twice.
• OrionEnvelope: one HTTP contract for the whole API: typed { data, meta } for success, RFC 9457 problem details for failure.
• OrionRate: token-bucket and sliding-window rate limiting.
• OrionGrant and OrionLedger: permissions and policies, and the full lifecycle of API keys.
• OrionStream: Server-Sent Events with bounded buffers and heartbeats.

Cross-cutting

• OrionLens carries a correlation id through async calls and across HTTP; OrionShade masks secrets and personal data before they reach a log; OrionCache does cache-aside without a stampede; OrionResilience retries with jitter over OrionClock, so a test of a retry takes no time.

Seeing them together​

Package pages show one library at a time. OrionShowcase shows how they work together: a production-shaped banking sample in which one money transfer passes through OrionGuard's validation, OrionLock's distributed locks, OrionAudit's change capture, OrionPatch's outbox, OrionKey's typed IDs and OrionVault's encrypted personal data. Assembling that story is much harder than any single package looks, and that is the point of the sample.

Why share them​

I wrote these because I needed them, and I publish them so that nobody else has to write them again. Every library is MIT-licensed, has its documentation on this site, and takes issues on GitHub. The ones that need no database or broker can be tried right here in the playground.

If you use one of them, or tried one and it didn't fit, I would like to know why. That is the most useful thing anyone can tell me.

What Claude Code learned an hour ago about why a table looks the way it does, Codex has no idea about. There is no single record of which agent ran which command. Every CLI has its own list of MCP servers, so I connect GitHub four times. And if I want an agent to ask me before it runs git push, I have to set that up in four places, four different ways.

Derbent is the tool I wrote to pull that together. It is free and open source.

What it does​

Derbent is a gate between coding agents and their tools. Claude Code, Codex, GitHub Copilot CLI and Antigravity CLI connect to it as one ordinary MCP server, and your own MCP servers sit behind it. Every tool call passes through the gate, and four things happen there.

Shared memory. The agents get memory_write, memory_search and memory_read. A note one agent writes in a repository, another agent working in the same repository can find. Search is full-text, and a git worktree shares the memory of the repository it was added from.

Rules. Allow, deny or ask, by agent, tool and argument. Rules are tried in order and the first match wins. A tool an agent may not use is not even listed to it, and calling it by name is refused anyway.

Approvals. A call that hits an ask rule waits until you decide. Run derbent in a terminal of its own and the waiting calls are at the top: approve once, approve for the rest of that agent's session, or deny. The same works from any shell with derbent approve 12. If nobody answers, the call is denied when the timeout runs out, and the agent is told why.

Receipts. Every call that passes through the gate leaves a receipt: which agent, which tool, which arguments, what was decided and what came of it. The receipts form a hash chain, and derbent verify tells you whether one was edited or removed. Secrets are masked before anything is stored.

The agents' own tools, their shell commands and file edits, don't go through MCP. But all four CLIs can run a command of your choice before each tool call. Make that command derbent gate, and a git push goes through the same rules, the same approval and the same receipt chain.

The name​

In Turkish history, a derbent was a guarded post on a mountain pass or a dangerous road. The men who kept it were responsible for the pass, and in return were spared some taxes. They decided who went through and kept a record of everyone who did.

Every English word I tried (gatekeeper, warden, checkpoint, bastion) was either another security product's name or too general. Derbent says exactly what the tool does, and nobody else uses it.

How it is built​

The most important decision is that there is no daemon. The obvious shape is a hub every agent connects to, but that hub has to start before any agent, stay alive, restart after a crash, and guard the port it listens on. In Derbent every agent session starts its own gate process, and they all open the same SQLite file. Nothing has to run first, there is no open port, and a crash takes down one agent's gate, not everyone's.

That has a price, and the documentation says so: every agent session starts its own copy of the servers behind the gate, and approvals are noticed by polling rather than instantly.

It is written in Go. Claude Code starts derbent gate once for every tool call, so every shell command waits for a process to start, decide and exit. A Go binary starts without loading an interpreter, and it is one file for Windows, macOS and Linux that asks for nothing else on the machine.

What it does not do​

Writing down what Derbent doesn't do mattered as much as what it does.

• The agent name is a label, not authentication. Any process running as you can call itself anything.
• It is not a boundary against an agent that already has a shell as you. Such an agent could run derbent approve itself, or write the database. Approvals guard against mistakes and against prompt injection that stays inside MCP.
• The chain doesn't catch everything on its own. It finds changes in the middle; a cut-off tail or a chain rewritten from the start only shows against a copy of the head hash you keep somewhere else.
• Glob rules don't understand shell syntax. git push* doesn't match cd repo && git push.

The worst thing a security tool can do is promise more than it does. Used knowing its limits, Derbent helps a lot; trusted without knowing them, it would do harm.

Try it​

go install github.com/tunahanaliozturk/derbent/cmd/derbent@latest

claude mcp add derbent -- derbent mcp --agent claude
codex mcp add derbent -- derbent mcp --agent codex

With just that, the two agents share one memory and every call is recorded. The documentation covers rules, approvals and the hooks.

If you use more than one coding agent, I would like to hear from you, especially about which calls you would want held for approval. Issues and ideas are welcome on GitHub.