kKastor

Open source AI toolchain

Kastor is a
source-of-truth layer
for AI agents.

Define agents, tools, prompts, models, and targets in HCL. Validate the spec. Compile it to runnable framework code. Later, reconcile hosted agents with Terraform-style plan/apply/state.

View on GitHubRead the quickstart
~/kastor
$ kastor init demo
scaffolded 6 files, ready to build

$ kastor validate demo
ok: 1 agent, 1 tool, 1 prompt

$ kastor build demo
wrote demo/gen/langgraph

$ kastor plan examples/weather
  + agent.forecast
  + agent.geocoder
  + agent.weather

Plan for target.memory:
3 to create, 0 to update, 0 to delete

Status

Early proof of concept, with a working local loop.

Kastor is not a hosted service yet. Today it is a small compiler and reconciler that makes the agent contract explicit before runtime code appears.

Working today

  • scaffold a new module with kastor init
  • parse .agent, .tool, .prompt, and kastor.hcl
  • validate references and prompt variables
  • build runnable LangGraph and eve projects
  • run kastor plan / kastor apply / kastor destroy against the built-in in-memory platform
  • reconcile hosted Claude Managed Agents with target "claude_agents"
  • local state file, three-way diffs, and drift detection
  • examples: weather agent, content scheduler, and support triage

Planned

  • structured --json diagnostics and plans
  • more hosted platform providers

Demo

From HCL files to generated agent code.

How it works

One module, two output paths.

1. Module
.agent + .tool + .prompt + kastor.hcl
2. Validate
kastor validate
3. Choose an output path
kastor buildLangGraph project
kastor plan/applyhosted agents

Example HCL

The agent contract lives in the spec.

weather.agentsource of truth
agent "weather" {
  description = "Answers weather questions for a location and date"

  model         = model.fast
  system_prompt = prompt.weather_system
  tools         = [tool.web_search]

  input "location" {
    type        = string
    description = "The location to get weather for"
  }

  input "date" {
    type     = string
    optional = true
  }

  output "weather" {
    type = string
  }
}

Why Kastor

Agent systems need a reviewable contract.

Agents often end up split across framework code, prompt files, tool glue, platform UI settings, and environment configuration. Kastor's bet is that agents need a versionable, reviewable, declarative contract before they become serious software.

Typed surface

Inputs, outputs, prompts, tools, models, and targets become explicit declarations.

Validation first

References and prompt variables fail before generated code or hosted resources drift.

Generated output

The generated code is an output; the Kastor spec remains the source of truth.

What Kastor is not

Kastor is not an agent runtime. Frameworks like LangGraph still execute agents. Hosted platforms still run managed agents. Kastor sits above them as the declarative source-of-truth layer.

Why not Terraform?

Kastor starts at the spec, before remote resources.

Terraform is great for managing remote resources. A Terraform provider for hosted agents may make sense later. Kastor starts one layer earlier: the agent spec itself. The same Kastor module should be able to generate runnable framework code with kastor build or reconcile hosted platform agents with kastor plan / kastor apply.

Why not just LangGraph?

LangGraph runs agents. Kastor defines them.

LangGraph is a runtime/framework. Kastor is not trying to replace it. Kastor defines the agent contract and can generate a LangGraph project from that spec. The generated code is an output; the Kastor module is the source of truth.

Roadmap

Next work is practical and toolchain-shaped.

  • polish LangGraph codegen ergonomics
  • hosted AI providers integration
  • better language reference docs
  • more real-world examples
  • eventually: generated docs and MCP/server interface for agent-operated workflows

Get involved

Follow the project on GitHub.

Kastor is early, open-source, and built from the design in the repository.

Follow the project on GitHub