Get This Tool
Kastor
Pricing
- Model
- Free
Summary
Agent systems sprawl fast — prompts in one file, tool glue in another, model config buried in environment variables, and nobody can tell you what the agent's actual contract is until it breaks in production. Kastor is a CLI compiler that forces that contract to exist before any runtime code does.
Kastor lets you define agents, tools, prompts, and models in HCL, validate the spec for broken references and unresolved prompt variables, then compile it to a runnable LangGraph project. The plan/apply/destroy loop catches drift between your spec and what's actually deployed — the same mental model as Terraform, applied one layer earlier. The vendor explicitly labels this an early proof of concept with a working local loop; hosted provider integration is on the roadmap but not shipped. Code generation targets LangGraph only. Teams needing a runtime, a UI, or anything beyond a local CLI will be assembling the rest of the stack themselves.
Bottom line: Pick Kastor when you want a reviewable, version-controlled contract locking down agent inputs, outputs, and tool references before a single line of framework code gets written — but if your project needs anything beyond LangGraph output or a local state file, you are waiting on a roadmap.
Community Performance Report Card
No community ratings yet. Be the first to rate this tool!
Community Benchmarks Community
Sign in to submit a benchmarkNo community benchmarks yet. Be the first to share a real-world data point.
Pros
Sign in to edit- HCL validation catches broken tool references and unresolved prompt variables before code generation runs, so a whole class of silent misconfiguration errors never reaches the LangGraph runtime.
- Typed agent inputs and outputs become explicit declarations in the spec, which means API contracts between agents are reviewable in a pull request rather than inferred by reading framework code.
- Plan/apply/destroy semantics with a local state file surface drift between spec and deployed state, so when an agent's behavior diverges from its declared contract you have a diff rather than a debugging session.
- Fully open-source with no hosted dependency, so the entire toolchain runs locally and there is no vendor lock-in to a platform that may change pricing or availability.
- Spec-first workflow keeps the HCL module as the source of truth and treats generated LangGraph code as a disposable output, which means regenerating after a spec change does not require manually reconciling hand-edited framework files.
Cons
Sign in to edit- Code generation targets LangGraph exclusively at this stage; teams whose stack uses a different agent framework get a spec validator with no compilation output, which means they are handwriting the translation layer themselves.
- The only deployment target is a local in-memory platform — hosted provider integration is listed on the roadmap but not available, so any team that needs to reconcile against a real hosted agent service is blocked until that ships.
- The vendor explicitly describes this as an early proof of concept; language reference docs are listed as incomplete and real-world examples are limited to a weather agent and a content scheduler, which means teams taking this into a production codebase are operating ahead of the documentation.
- There is no API and no programmatic interface, so integrating Kastor into an existing CI pipeline or tool that expects a library rather than a CLI requires shelling out — a friction point that pushes teams with mature automation toward building their own spec validation layer or waiting for a more complete release.
Community Reviews
Sign in to write a reviewNo reviews yet. Be the first to share your experience.
About
- Platforms
- CLI (Go)
- API Available
- No
- Self-Hosted
- Yes
- Last Updated
- 2026-07-09T12:24:32.179Z
Best For
Who it's for
- Developers seeking declarative specs for agent systems
- Teams requiring reviewable contracts before framework code
- Projects needing explicit typing of agent inputs/outputs/tools
What it does well
- Defining versionable agent contracts in HCL before runtime implementation
- Validating agent specs including tool references and prompt variables
- Generating runnable LangGraph projects from declarative specs
- Managing agent drift detection with plan/apply semantics locally
Integrations
Discussion Community
Sign in to commentNo discussion yet. Sign in to start the conversation.
Compare Kastor
Spotted incorrect or missing data? Join our community of contributors.
Sign Up to ContributeCommunity Notes & Tips Community
Sign in to contributeBe the first to contribute. General notes, observations, gotchas, and tips from people who use this tool day-to-day.
Frequently Asked Questions
- Is Kastor free?
- Yes — Kastor is fully free to use. There is no paid tier.
- Is Kastor open source?
- Yes. Kastor is open source.
- Can I self-host Kastor?
- Yes. Kastor supports self-hosting on your own infrastructure.
- What platforms does Kastor support?
- Kastor is available on: CLI (Go).
Hours Saved & ROI Stories Community
Sign in to contributeBe the first to contribute. Concrete time/cost savings, with context. e.g. "Cut my code review backlog from 4h to 45m per week."
Curated lists that include this category
Kastor sits between your design intent and your framework code. You write `.agent`, `.tool`, and `.prompt` files in HCL, run `kastor validate` to catch dangling references and missing prompt variables before they become runtime surprises, then run `kastor build` to emit a LangGraph project. The generated code is treated as an artifact — the HCL spec is the source of truth. A separate `kastor plan / kastor apply / kastor destroy` loop uses a local state file and three-way diffs to detect drift between the spec and what’s been deployed, mirroring Terraform’s reconciliation semantics.
The differentiating bet here is typing the agent surface explicitly: inputs have declared types and optional flags, outputs are named and typed, tools and prompts are referenced by name and validated before compilation. This means the failure mode of discovering a broken tool reference or an undefined prompt variable at agent runtime is pushed back to `kastor validate` — a deterministic, scriptable step you can run in CI before any framework code is touched.
Kastor fills a specific gap: the contract layer between design and implementation. It is not a runtime — LangGraph still executes the agents Kastor defines. It is not a hosted platform — the vendor states no hosted service exists yet, and the in-memory platform is the only target available locally. Teams that need multi-framework output beyond LangGraph, a visual editor, or a managed deployment surface will not find those here. At this stage, the realistic audience is developers who want declarative, diffable agent specs as a first-class artifact in their repo, not teams looking for a production-grade deployment pipeline.