I’ve been building tooler, an open-source runtime written in Rust designed to give developers, DevOps workflows, and AI agents a consistent set of real-world tools.
Instead of letting an agent rely on arbitrary shell commands, tooler provides structured capabilities for HTTP requests, databases, filesystems, processes, logs, Git/GitHub, deployments, health checks, systemd, cron, remote hosts, and reusable playbooks.
It also exposes its capabilities through MCP, making them directly accessible to AI agents.
The idea is simple:
LLM → reasoning and planning → tooler → deterministic execution
This creates a clean separation between what the agent decides to do and how those operations are safely and consistently executed.
tooler is built in Rust, distributed as a standalone binary, and designed for both humans and AI agents.
In this post, I’ll introduce the project, its architecture, why I built it, and how I’m exploring tooler as an execution layer for increasingly complex agentic workflows.
Top comments (1)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
The execution boundary is the strongest part of this architecture. Giving agents structured capabilities instead of unrestricted shell access creates a much better control plane for deterministic automation.
I would push the design further with capability based authorization, ephemeral credentials, syscall isolation, resource quotas, and an explicit execution policy engine. Every tool invocation should produce a signed audit event containing intent, parameters, authorization context, execution result, and rollback metadata.
For MCP specifically, I would separate planning permissions from execution permissions. An agent could propose a deployment, while policy evaluates blast radius, target environment, required capabilities, and approval state before tooler executes anything.
Playbooks could also become composable state machines with idempotency guarantees and compensation actions. That would make failed multi step DevOps workflows recoverable instead of relying entirely on the model to reason about partial state.
Rust is an excellent fit for this execution layer. Really interesting direction, and I would enjoy collaborating on agent safety and orchestration architecture.