Show HN: Castra – Strip orchestration rights from your LLMs

Thanks! This took a while (approximately 30 days) to get to this point.

The market basically relies on two main alternative approaches right now, both of which have their merits:

1. File-based Memory (Markdown/Artifacts): Instead of just relying on the context window, you prompt the agent to maintain its state in local files (e.g., a PLANNING.md or a TASKS.md artifact). It’s a step up, but text files lack relational integrity. You are still trusting the LLM to format the file correctly and not arbitrarily overwrite critical constraints.

2. The Orchestrator Agent (Dynamic Routing): Using a frontier model as a master router. It holds a list of sub-agents (routes) and is trusted to dynamically evaluate the context, route to the correct agent, and govern their behavior on the fly. The merit here is massive flexibility and emergent problem-solving.

I went in the opposite direction.

The trade-off with Castra is that it trades all that dynamic flexibility for a deterministic SQLite state machine. The demerit (though I consider it a feature) is that it is incredibly rigid and, honestly, boring. There is no 'on-the-fly' routing. It’s an unyielding assembly line. But for enterprise SDLC, I don't want emergent behavior; I want predictability.

The alternatives optimize for agent autonomy. Castra optimizes for agent constraint.

To clarify the architecture: The LLM doesn't have access to the ledger. That’s the entire point of Castra.

The LLM only has access to the CLI binary. The SQLite database is AES-256-CTR encrypted at rest. If an LLM (or a human) tries to bypass the CLI and query the DB directly, they just get encrypted garbage. The Castra binary holds the device-bound keys. No keys = no read, and absolutely no write.

As for the 'LLM-generated' comment; I’m flattered my incident report triggered your AI detectors, but no prompt required. That’s just how I write (as you can probably tell from my other replies in the thread). Cheers :)

FaultWall sounds like we're absolutely on the same paranoid wavelength. Treating the LLM as a hostile/untrusted actor at the data plane is the only way this scales to enterprise.

To answer your question: No, we actually completely eliminated destructive DB drift on the state machine, but we did it by air-gapping the database entirely. The agents in Castra don't write SQL and don't have a DB connection. They only have access to the compiled Go CLI. If an agent tries to hallucinate a destructive state change, the CLI simply rejects the command with a structured stderr HATEOAS response telling it to fix its syntax.

That said, having Castra govern the workflow orchestration while FaultWall governs the target application's data plane sounds like the ultimate 'zero-trust' synthetic labor stack. If you have a specific test case in mind, or a feature request that would help integrate your system into Castra's workflows, feel free to open an issue on the GitHub repo. I'd be happy to take a look and see how we can bridge it.

[dead]