6 ms·

Show HN: Kastor – Terraform-style specs for AI agents

33 points by weirdguy 2mo ago

weirdguy 2mo ago
hey HN, it's first time posting something here. I’m building Kastor: Go CLI/declarative language/config for AI agents. the motivation: agent definitions often end up spread across framework code, prompt files, tool files/mcps, platform UI settings, and env vars. that makes them hard to review, diff, reproduce or move. Kastor is an attempt to put a source-of-truth layer above that. right now the working proof of concept is narrow: - .agent / .tool / .prompt files - HCL parser + validation - dependency/reference checks - LangGraph codegen - runnable weather example - runnable content scheduler example the long-term direction is Terraform-ish: - build: compile to framework code - plan/apply: reconcile hosted platform agents - state: track remote resources and detect drift I’m deliberately not trying to build another agent runtime. the thing I’m trying to validate is whether agents need something closer to IaC: versionable, reviewable, declarative source of truth. would appreciate any kind of feedback, especially on the language/design.
handfuloflight 2mo ago
The website is down?
- weirdguy 2mo ago
  oh, it's not, just root domain (non-www) without redirect
  - handfuloflight 2mo ago
    That's not working either.
    - weirdguy 2mo ago
      try with www, should work, the apex zone still did not propagate for whatever reason
      - handfuloflight 2mo ago
        Works now.
Leewen 2mo ago
works for me. terraform for agents? neat
- weirdguy 2mo ago
  thanks — that’s the direction. current version is still just validate + LangGraph codegen, but plan/apply/state is the part I’m trying to get to next
  - Leewen 2mo ago
    GL
empath75 2mo ago
The problem right now with something like this is you're trying to nail jello to a wall. People haven't figured out what an agent is yet, and trying to crystalize what people happen to be doing right now means in a few months, you're going to be obsolete.
- weirdguy 2mo ago
  I agree with you don't think the "agent" abstraction is stable enough to standardize the behavior/runtime layer yet. thing I'm trying to test is smaller: is that possible to standardize the outer contract around agents? what inputs does it accept? what outputs does it promise? what model does it use? what prompt/template does it depend on? what tools can it call? what target should it be built or applied to? so here it is intentionally not trying to describe the full control loop or become a runtime. it's more like a source-of-truth layer for the parts that are already showing up everywhere, even if the runtime patterns keep changing underneath. I might be wrong, but my bet is that the runtime layer will keep changing, while the need for reviewable/diffable agent contracts will not.
- reactordev 2mo ago
  You mean Claude…
  - giancarlostoro 2mo ago
    Claude is a model, an agent is more like the full solution. Some would call Claude Code itself an agent. Agents do things, models are just models until you use them.
    - reactordev 2mo ago
      What are you going on about? I was saying that they didn’t write any code it was all Claude. Obviously using Claude code.
      - giancarlostoro 2mo ago
rnagulapalle 2mo ago
[flagged]
Dan-SC 2mo ago
[flagged]
whattheheckheck 2mo ago
Why not just make an actual terraform module?
- weirdguy 2mo ago
  Good question For hosted agents only, a Terraform provider probably makes sense. The reason I didn’t start there is that Kastor has two paths: 1 - build: compile the spec into framework code, e.g. LangGraph 2 - plan/apply for agents hosted on platforms Terraform is great for the second path, but awkward as the primary tool for the first one. I want the same agent spec to be able to produce code or manage a remote agent. So I can imagine a Terraform provider being one target later, but I don’t think Terraform itself is the right tool/place for the whole thing.
  - whattheheckheck 2mo ago
    Im wondering if you can expand it using TLA+ some how. I like the declarative language that compiles down to langgraph idea. Langgraph or hamilton/burr are two strong contenders for state machines. Maybe mix dbos or Temporal in there and you could almost have something to full declare the whole system
    - weirdguy 2mo ago
      The codegen side is target-agnostic on purpose, LangGraph is just the first target. Burr (thanks for educating about that piece of tech) could be a good N-one, its state/transition model maps onto the spec real pretty. Vercel's eve made a similar bet btw (files as source of truth, durable execution built in), except it's a runtime with its own platform underneath. With Kastor I want to stay one layer above and emit code for whatever runtime you pick. Anyways, would love any kind of help to shape the direction, repo discussions and codebase is open :)
    - weirdguy 2mo ago
      UPD: Looked into burr from dagworks deeper, it's actually a good target to support the codegen for, will investigate today and add into the scope of upcoming things. Thank you for showing those things!

33 points by weirdguy 2mo ago

hey HN, it's first time posting something here. I’m building Kastor: Go CLI/declarative language/config for AI agents. the motivation: agent definitions often end up spread across framework code, prompt files, tool files/mcps, platform UI settings, and env vars. that makes them hard to review, diff, reproduce or move. Kastor is an attempt to put a source-of-truth layer above that. right now the working proof of concept is narrow: - .agent / .tool / .prompt files - HCL parser + validation - dependency/reference checks - LangGraph codegen - runnable weather example - runnable content scheduler example the long-term direction is Terraform-ish: - build: compile to framework code - plan/apply: reconcile hosted platform agents - state: track remote resources and detect drift I’m deliberately not trying to build another agent runtime. the thing I’m trying to validate is whether agents need something closer to IaC: versionable, reviewable, declarative source of truth. would appreciate any kind of feedback, especially on the language/design.

handfuloflight 2mo ago

The website is down?

weirdguy 2mo ago
oh, it's not, just root domain (non-www) without redirect
- handfuloflight 2mo ago
  That's not working either.
  - weirdguy 2mo ago
    try with www, should work, the apex zone still did not propagate for whatever reason
    - handfuloflight 2mo ago
      Works now.

Leewen 2mo ago

works for me. terraform for agents? neat

weirdguy 2mo ago
thanks — that’s the direction. current version is still just validate + LangGraph codegen, but plan/apply/state is the part I’m trying to get to next
- Leewen 2mo ago
  GL

empath75 2mo ago

The problem right now with something like this is you're trying to nail jello to a wall. People haven't figured out what an agent is yet, and trying to crystalize what people happen to be doing right now means in a few months, you're going to be obsolete.

weirdguy 2mo ago
I agree with you don't think the "agent" abstraction is stable enough to standardize the behavior/runtime layer yet. thing I'm trying to test is smaller: is that possible to standardize the outer contract around agents? what inputs does it accept? what outputs does it promise? what model does it use? what prompt/template does it depend on? what tools can it call? what target should it be built or applied to? so here it is intentionally not trying to describe the full control loop or become a runtime. it's more like a source-of-truth layer for the parts that are already showing up everywhere, even if the runtime patterns keep changing underneath. I might be wrong, but my bet is that the runtime layer will keep changing, while the need for reviewable/diffable agent contracts will not.
reactordev 2mo ago
You mean Claude…
- giancarlostoro 2mo ago
  Claude is a model, an agent is more like the full solution. Some would call Claude Code itself an agent. Agents do things, models are just models until you use them.
  - reactordev 2mo ago
    What are you going on about? I was saying that they didn’t write any code it was all Claude. Obviously using Claude code.
    - giancarlostoro 2mo ago

rnagulapalle 2mo ago

[flagged]

Dan-SC 2mo ago

[flagged]

whattheheckheck 2mo ago

Why not just make an actual terraform module?

weirdguy 2mo ago
Good question For hosted agents only, a Terraform provider probably makes sense. The reason I didn’t start there is that Kastor has two paths: 1 - build: compile the spec into framework code, e.g. LangGraph 2 - plan/apply for agents hosted on platforms Terraform is great for the second path, but awkward as the primary tool for the first one. I want the same agent spec to be able to produce code or manage a remote agent. So I can imagine a Terraform provider being one target later, but I don’t think Terraform itself is the right tool/place for the whole thing.
- whattheheckheck 2mo ago
  Im wondering if you can expand it using TLA+ some how. I like the declarative language that compiles down to langgraph idea. Langgraph or hamilton/burr are two strong contenders for state machines. Maybe mix dbos or Temporal in there and you could almost have something to full declare the whole system
  - weirdguy 2mo ago
    The codegen side is target-agnostic on purpose, LangGraph is just the first target. Burr (thanks for educating about that piece of tech) could be a good N-one, its state/transition model maps onto the spec real pretty. Vercel's eve made a similar bet btw (files as source of truth, durable execution built in), except it's a runtime with its own platform underneath. With Kastor I want to stay one layer above and emit code for whatever runtime you pick. Anyways, would love any kind of help to shape the direction, repo discussions and codebase is open :)
  - weirdguy 2mo ago
    UPD: Looked into burr from dagworks deeper, it's actually a good target to support the codegen for, will investigate today and add into the scope of upcoming things. Thank you for showing those things!