Kastor Open Source: Managing Agents as Infrastructure

Someone Has Brought the Terraform Playbook to Agents

In early July, a project called Kastor quietly appeared on Hacker News with a very straightforward title: Show HN: Kastor – Terraform-style specs for AI agents. The author’s idea can be summed up in one sentence: if infrastructure can be managed with terraform apply, and Kubernetes can be managed with kubectl apply -f, then why are AI agents still glued together with handwritten Python code?

This isn’t the first project trying to make agents declarative, but it’s the closest thing I’ve seen so far to directly transplanting the IaC (Infrastructure as Code) paradigm. Even the naming is a tribute: Kastor / Castor, declarative configuration, state management, diff & apply — it’s practically HashiCorp’s mental model copied over intact.

What Problem Does It Actually Solve?

Right now, building even a moderately complex agent usually looks something like this: start with LangChain or LlamaIndex, hardcode a system prompt, register a few tools, then handwrite retry logic, fallbacks, and logging. Every time you switch models, you have to touch the code again. In team collaboration, the “definition” of the agent ends up scattered across Python files, YAML configs, and environment variables. During code review, it’s almost impossible to tell what part of the agent’s behavior actually changed.

Kastor’s solution is to put the agent’s entire definition — which model it uses, which tools are attached, what guardrails exist, how routing works, and what upstream/downstream dependencies it has — into a single declarative spec. Something like this:

agent \"support_triage\" {
  model    = \"gpt-4o\"
  fallback = \"claude-3-5-sonnet\"

  system_prompt = file(\"./prompts/triage.md\")

  tool \"search_kb\" {
    source = \"./tools/kb.py\"
  }

  tool \"create_ticket\" {
    source = \"./tools/jira.py\"
    scopes = [\"write:issue\"]
  }

  guardrail \"pii_filter\" {
    action = \"redact\"
  }

  route \"escalation\" {
    when = \"sentiment < -0.5\"
    to   = agent.human_handoff
  }
}

Then kastor plan tells you how the agent will transition from one state to another after the change, and kastor apply performs the actual deployment. For anyone with a DevOps background, the workflow feels instantly familiar.

Why This Approach Is Worth Watching

I’ve spent several years in the AI industry and have seen too many agent frameworks go through the cycle of “flashy demo” to “production disaster.” Teams that actually deploy agents to production eventually end up reinventing the same wheels:

• Version management: When an agent definition changes, how do you do gradual rollout and rollback?
• Environment isolation: How do you keep dev / staging / prod configurations consistent?
• Dependency tracking: If Agent A depends on Agent B and B goes down, what happens? Who monitors it?
• Review workflows: Changing a prompt is effectively changing a piece of “program logic,” but diffs don’t clearly show business intent.

These are exactly the kinds of problems Terraform solved for cloud infrastructure a decade ago. Kastor’s author is clearly operating from the same premise: agents are the new infrastructure, so they should be managed like infrastructure.

I agree with that assessment. Most agent orchestration frameworks from the past two years are still in the phase of “using a Python DSL to make coding more pleasant.” Fundamentally, they’re SDKs. Kastor, on the other hand, looks more like a control plane: it doesn’t care how your agents run, only about the diff between declared state and actual state.

Technical Details: More Than Just YAML With a Different Skin

After digging through the repo, a few design choices stood out.

First, the state file is a first-class citizen. Just like Terraform, Kastor maintains state that records the currently deployed agent topology. That means you can run kastor state show agent.support_triage to inspect the exact production configuration, instead of guessing by reading Git history.

Second, the provider model. Model integrations are abstracted as providers, meaning any backend conforming to the interface can theoretically plug in. The README already lists OpenAI, Anthropic, and local Ollama providers. The community will probably add DeepSeek and Gemini within weeks. For teams using multiple models together, this provider abstraction is much cleaner than stuffing if-else logic into business code.

Third, modularization. Same concept as Terraform modules: a “customer support agent cluster” can be packaged as a module containing triage, RAG, and escalation agents, exposing a few variables externally. Other projects can reuse it directly without copy-pasting.

Fourth, dry-run behavior during the plan phase. I think this is the killer feature. After changing a prompt, you can run kastor plan, and the system executes a small set of test cases against both the old and new configurations, diffing the behavioral changes. This addresses one of the hardest problems in prompt engineering — you never really know what changing a single word will do to an agent.

Compared to Existing Solutions

There are several unavoidable comparisons:

• LangGraph: graph-based orchestration, code-first, highly flexible, but heavyweight. Great for prototyping, painful for production management.
• CrewAI / AutoGen: focused on multi-agent collaboration and “role-playing” paradigms, but configuration and runtime are tightly coupled.
• Dify / Coze: low-code platforms with drag-and-drop UIs, suitable for non-engineers, but with almost no support for DevOps workflows.
• Kubernetes Operators for Agents (such as kagent): conceptually similar, but deeply tied to Kubernetes with a steep learning curve.

Kastor’s positioning is fairly unique: it’s aimed at engineering teams that already think in DevOps terms, bringing agents into existing GitOps pipelines instead of forcing teams to learn an entirely new paradigm. It doesn’t provide a runtime — only definition and deployment. The runtime can be anything, including direct calls to aggregation APIs.

Some Reservations

That said, a few caveats.

The ceiling of declarative systems. Terraform itself faced criticism for this years ago — once business logic becomes complex, HCL starts running out of expressive power, forcing people to escape through hacks like local-exec. Agent behavior is far more complex than cloud resources. Many workflows are inherently imperative (“if the user says X, check A first before deciding whether to call B”). Kastor currently relies on route rules and conditional expressions, but it’s unclear how many real-world scenarios that can cover.

The ecosystem is the weak point. Terraform succeeded because nearly every cloud vendor provided official providers. Kastor is currently still a solo project. Both model providers and tool providers need to be built by the community from scratch. The first six months will likely be rough.

Testing standards don’t exist yet. The behavioral diffing in kastor plan depends on test cases, but defining “correct behavior” for agents is inherently difficult. This probably needs integration with the evals ecosystem (such as Braintrust or Langfuse) before it becomes truly useful.

One More Thing

If you want to try Kastor with multiple models, OpenAI Hub is a convenient option — a single key gives direct access to GPT, Claude, Gemini, and DeepSeek, all compatible with the OpenAI format. In Kastor, you only need to configure one provider to switch between all models, without applying for separate keys or integrating separate SDKs for each vendor. For teams implementing fallback strategies, especially in mainland China where direct connectivity matters, this is practically a necessity.

Is It Worth Following?

My view is: this is a project heading in the right direction, and the timing finally feels right. In 2024, declarative agents were still too early — people hadn’t even figured out what agents were supposed to look like. By 2026, multi-model, multi-tool, multi-agent collaboration has become standard in production, and the question of “how do we manage them?” has finally overtaken “how do we build them?” That’s the environment where projects like Kastor can survive.

That said, one person alone can’t build something on Terraform’s scale. Whether Kastor takes off depends on whether major companies or active communities step in to build the provider ecosystem over the next six months. For now, it’s worth starring on GitHub and maybe trying in a new project. For production use, though, it’s still worth waiting another version or two.

References

• Kastor GitHub Repository - Project homepage and documentation, including spec syntax explanations and examples