11–20 of 25 posts
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.
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.
You mean Claude…
Earlier quoted context omitted.
You mean Claude…
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.
Earlier quoted context omitted.
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.
What are you going on about? I was saying that they didn’t write any code it was all Claude. Obviously using Claude code.
Why not just make an actual terraform module?
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.