I keep seeing the same pattern with AI agents: the demo works, the first workflow is exciting, and then the boring operational questions show up.
What is installed?
Which model/provider/config is this run using?
What tool calls happened?
Which actions needed approval?
Can I replay the failure, resume the run, or prove what changed?
That gap is what we are building around at Armorer Labs.
Armorer
Armorer is a local control plane for AI agents. The goal is to make local and self-hosted agent workflows feel less like scattered scripts and more like supervised jobs: installable, configurable, observable, stoppable, and recoverable.
Repo: https://github.com/ArmorerLabs/Armorer
The framing I like is: not another agent framework, but the local operations layer around the agents you already want to run.
Armorer Guard
Armorer Guard is the companion idea for runtime decisions. If an agent, workflow, MCP server, or tool gateway makes a decision, I want a structured receipt for it:
- what was requested
- what policy/rule/gate evaluated it
- what evidence was used
- what decision was made
- what changed afterward
Repo: https://github.com/ArmorerLabs/Armorer-Guard
Why this matters
I do not think production agent systems will be trusted because the model sounds confident. They will be trusted because they leave boring, inspectable records.
If you are building or running agents locally, I would love feedback on both repos. Stars are obviously helpful, but the more useful thing is sharp criticism: what would make these tools worth installing in your own workflow?
답글 남기기