Most .NET backends end up needing the same dozen things: validation, a distributed lock, an audit trail,\nan outbox, encrypted columns, typed IDs, idempotent endpoints, rate limits, retries. Each team builds them\nagain, a little differently, and each version is wrong in its own small way.
\nThe Orion family is my answer to that: small, focused libraries for those problems, built to one quality\nbar and published on NuGet.
\nToday it is 24 libraries in 89 packages, downloaded more than 350,000 times. This post is about why they\nexist, what holds them together, and what each one is for.
\nEvery Orion library solves one problem and stands on its own. You add OrionLock because you need a lock,\nnot because you signed up for a platform. There is no deep dependency web between them; pick only what\nyou need.
\nThat also means saying no. OrionPatch is a transactional outbox, and its documentation says plainly that\nsagas are out of scope: if you need a process manager, reach for MassTransit or Wolverine instead. A\nlibrary that knows where it stops is easier to trust than one that wants to be everything.
\nBuilding the libraries one after another, I noticed five things being implemented again and again, and\ndrifting apart each time:
\nThey now live once, in Orion.Abstractions. Its surface is frozen at 1.0: every contract stays source- and\nbinary-compatible across the whole 1.x line, so one library can't break under a sibling's upgrade. The\nrules 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\ntakes one, and it lets a test move time forward instead of waiting. OrionResult gives expected failures a\nshape: a zero-allocation Result<T>, an Option<T>, and a structured Error with a code, a kind and field\nerrors.
Input and the domain
\nData
\nOFFSET is a table scan.Messaging and consistency
\nSaveChanges transaction and dispatch at least once; on the other side, apply each message's effect\nexactly once.Coordination
\nHTTP and APIs
\n{ data, meta } for success, RFC 9457\nproblem details for failure.Cross-cutting
\nPackage pages show one library at a time. OrionShowcase shows how they work together: a\nproduction-shaped banking sample in which one money transfer passes through OrionGuard's validation,\nOrionLock's distributed locks, OrionAudit's change capture, OrionPatch's outbox, OrionKey's typed IDs and\nOrionVault's encrypted personal data. Assembling that story is much harder than any single package looks,\nand that is the point of the sample.
\nI wrote these because I needed them, and I publish them so that nobody else has to write them again. Every\nlibrary 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\nplayground.
\nIf you use one of them, or tried one and it didn't fit, I would like to know why. That is the most useful\nthing anyone can tell me.
", "url": "https://tunahanaliozturk.dev/blog/the-orion-family", "title": "Why I built the Orion family", "summary": "Most .NET backends end up needing the same dozen things: validation, a distributed lock, an audit trail,", "date_modified": "2026-09-30T00:00:00.000Z", "author": { "name": "Tunahan Ali Öztürk", "url": "https://github.com/tunahanaliozturk" }, "tags": [ "dotnet", "orion", "open-source" ] }, { "id": "https://tunahanaliozturk.dev/blog/why-i-built-derbent", "content_html": "I use more than one coding agent on the same repositories. Claude Code works on one thing, Codex on\nanother, and now and then I ask Copilot CLI something. Each of them is good at its job, and none of them\nknows what the others did.
\nWhat Claude Code learned an hour ago about why a table looks the way it does, Codex has no idea about.\nThere is no single record of which agent ran which command. Every CLI has its own list of MCP servers, so\nI connect GitHub four times. And if I want an agent to ask me before it runs git push, I have to set\nthat up in four places, four different ways.
Derbent is the tool I wrote to pull that together. It is free and open source.
\nDerbent is a gate between coding agents and their tools. Claude Code, Codex, GitHub Copilot CLI and\nAntigravity CLI connect to it as one ordinary MCP server, and your own MCP servers sit behind it. Every\ntool call passes through the gate, and four things happen there.
\nShared memory. The agents get memory_write, memory_search and memory_read. A note one agent\nwrites in a repository, another agent working in the same repository can find. Search is full-text, and\na 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\nwins. A tool an agent may not use is not even listed to it, and calling it by name is refused anyway.
\nApprovals. A call that hits an ask rule waits until you decide. Run derbent in a terminal of its\nown and the waiting calls are at the top: approve once, approve for the rest of that agent's session, or\ndeny. The same works from any shell with derbent approve 12. If nobody answers, the call is denied when\nthe 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\narguments, what was decided and what came of it. The receipts form a hash chain, and derbent verify\ntells 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\nrun a command of your choice before each tool call. Make that command derbent gate, and a git push\ngoes through the same rules, the same approval and the same receipt chain.
In Turkish history, a derbent was a guarded post on a mountain pass or a dangerous road. The men who kept it were\nresponsible for the pass, and in return were spared some taxes. They decided who went through and kept a\nrecord of everyone who did.
\nEvery English word I tried (gatekeeper, warden, checkpoint, bastion) was either another security\nproduct's name or too general. Derbent says exactly what the tool does, and nobody else uses it.
\nThe most important decision is that there is no daemon. The obvious shape is a hub every agent connects\nto, but that hub has to start before any agent, stay alive, restart after a crash, and guard the port it\nlistens on. In Derbent every agent session starts its own gate process, and they all open the same SQLite\nfile. Nothing has to run first, there is no open port, and a crash takes down one agent's gate, not\neveryone's.
\nThat has a price, and the documentation says so: every agent session starts its own copy of the servers\nbehind the gate, and approvals are noticed by polling rather than instantly.
\nIt is written in Go. Claude Code starts derbent gate once for every tool call, so every shell command\nwaits for a process to start, decide and exit. A Go binary starts without loading an interpreter, and it\nis one file for Windows, macOS and Linux that asks for nothing else on the machine.
Writing down what Derbent doesn't do mattered as much as what it does.
\nderbent approve itself, or write the database. Approvals guard against mistakes and against prompt\ninjection that stays inside MCP.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\nhelps a lot; trusted without knowing them, it would do harm.
\ngo 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\ndocumentation covers rules, approvals and the hooks.
\nIf you use more than one coding agent, I would like to hear from you, especially about which calls you\nwould want held for approval. Issues and ideas are welcome on\nGitHub.
", "url": "https://tunahanaliozturk.dev/blog/why-i-built-derbent", "title": "Why I built Derbent", "summary": "I use more than one coding agent on the same repositories. Claude Code works on one thing, Codex on", "date_modified": "2026-09-29T00:00:00.000Z", "author": { "name": "Tunahan Ali Öztürk", "url": "https://github.com/tunahanaliozturk" }, "tags": [ "derbent", "ai-agents", "mcp" ] } ] }