Kastor: A Terraform-style Declarative Layer for AI Agents

Kastor: A Terraform-style Declarative Layer for AI Agents

Kastor provides a declarative source-of-truth layer for AI agents, enabling developers to define agents, tools, prompts, and models in HashiCorp Configuration Language (HCL) and compile them into runnable framework code or managed platform resources. This approach treats agent configuration as a versionable, reviewable contract rather than fragmented settings spread across framework code, prompt files, and platform UIs.

Declarative Agent Specifications

Kastor uses a set of declarative files to define the complete contract of an AI agent. Instead of embedding configuration within runtime code, Kastor separates the definition from the execution.

File Types and Structure

A Kastor module consists of a directory tree containing the following file types:

  • .agent: Defines the agent's model, prompt, tools, inputs, and outputs, as well as its dependencies on other agents.
  • .tool: Specifies the tool interface and its implementation source.
  • .prompt: Contains the prompt template and identifies the required variables.
  • *kastor.hcl / .kastor: The project file used to define models, targets, and global defaults.

References within these files connect blocks by address (e.g., model.fast or tool.web_search) rather than file paths, which allows Kastor to build and validate a dependency graph at compile time.

Workflow: Build, Plan, and Apply

Kastor implements a toolchain that mimics the Terraform workflow to ensure that the intended state of an agent matches the actual deployed state.

Codegen Path (kastor build)

Kastor can compile a module into runnable framework code. For example, it can generate a full LangGraph project from a Kastor spec. The generated code is an output artifact and is not intended to be the source of truth; any changes should be made in the HCL specs and rebuilt.

Reconciliation Path (kastor plan / apply)

For hosted agents, Kastor provides reconciliation tools:

  • kastor plan: A read-only operation that compares the current spec against the state file and remote resources to identify drift or required changes.
  • kastor apply: Reconciles the hosted agents with the specification.
  • kastor destroy: Removes the managed agents.

Integration with LangGraph and MCP

Kastor currently supports generating LangGraph projects and integrating with the Model Context Protocol (MCP).

LangGraph Generation

When kastor build is executed for a LangGraph target, it writes the generated project to a specified output directory. This project includes a README.md detailing the agent's input/output contracts and tool bindings.

MCP Tooling

Tools in Kastor can be pinned to an MCP server and tool via a spec URI (e.g., mcp://search-server/tavily_search). The actual connection details, such as URLs and API keys, are handled via deployment configuration (like mcp_servers.json) rather than the spec itself, keeping secrets out of the version-controlled HCL files.

Architecture and Positioning

Kastor is not an agent runtime; it sits above the runtime layer to provide a standardized configuration interface.

Comparison to Frameworks and Terraform

  • Vs. LangGraph: While LangGraph is a runtime framework that executes agents, Kastor defines the contract and generates the project. Kastor is not a replacement for LangGraph but a layer that sits above it.
  • Vs. Terraform: While Terraform is designed for managing remote infrastructure resources, Kastor focuses on the agent specification itself. This allows Kastor to support both the generation of local framework code and the reconciliation of hosted platform agents.

Current Status and Capabilities

Kastor is currently an early proof of concept. Its current working features include:

  • Parsing of .agent, .tool, .prompt, and kastor.hcl files.
  • Validation of references and prompt variables.
  • In-memory platform support: The plan and apply workflows can be tested against a built-in in-memory platform target without requiring API keys.
  • State management: Local state files, three-way diffs, and drift detection.
  • Example implementations: Includes a weather agent and a content scheduler.

Sources