Comment by azurewraith
5 days ago
I feel you on the Claude pulsing thing. Running (or trying to) run Opencode with any model I could throw at it to perform useful work like the frontier/proprietary models do (a tall order I know) is where I started. everyone makes the problem bigger (massive contexts, massive number of parameters, more transformers (MoE)) but I started with how can we make small/local LLMs perform better (do more with less)
Opencode's plan/build is decent, like it is in Claude Code... state machines are the next evolution. model agnostic, tooling agnostic (where feasible)
> state machines are the next evolution
Yes but this solve just some part of a problem, it stops the agent from doing something. What would be more useful is forcing the agent to do something. To make up an example, let's say you want the agent to change a status in jira after it completes a task. With this framework you can deny the transition until the models changes the status in jira, but that doesn't mean the agent will do it.
If the agent generates structured JSON checked against a schema, then (to the limit of the ability of the agent to not generate correct JSON) the trick here is to have the transition request include a non-optional jira-update field. The agent can be malicious and give blank or useless jira updates, but if for example the transition to the next state requires a jira-state field selected from an enum (where the only options are valid next states, not necessarily every state; so include "fixed" and "not applicable" but not "open" or "new"; or whatever the business logic wants), then it restricts the ability of the agent to fail to make forward progress.
[dead]