You don't train an agent by talking to it more. You train it by writing down what you already solved.
Most people think improving an AI agent means better prompts, more context, a bigger model. That's not where the real gains come from.
Here's a small example. Say your agent needs to validate an email before saving it to a database. The first time, you might have it ask the AI to check: Is this a valid email? It works, but it's slow, it costs a token every time, and it can vary slightly between runs.
Once you actually know the rule, an email needs an @, a domain, and no spaces, you don't need AI for that anymore. You write it down as a skill. A plain set of steps the agent can just run.
Now that check is deterministic. Same input, same output, every single time. No API call. No waiting. No cost.
This is how I build every workflow now. Solve it once with AI, however messy that process is. Once it works, extract what you learned into a skill, a written rule the agent runs on its own from then on.
The agent doesn't get smarter by thinking harder about the same problem twice. It gets smarter because you stopped making it think about things you already figured out.
Curious how others are separating deterministic logic from genuinely judgment-based tasks in their own agents.
Clear and practical, thanks. Did anything surprise you along the way?
Interesting approach. What was the hardest part to get right?
What made you pick this stack over the alternatives?
Thanks for sharing the numbers, that makes it much easier to follow.
Thanks for writing this up. Bookmarking it for later.
Thanks for writing this up. Bookmarking it for later.
Solid lesson. Which channel has worked best for you so far?
Thanks for writing this up. Bookmarking it for later.
How did you decide this was worth building in the first place?
Thanks for writing this up. Bookmarking it for later.
Interesting take. Would you still recommend this approach to someone starting today?
The deterministic boundary is the real unlock. Let the model discover a rule once, then promote it into a validator with a regression example. That keeps the agent flexible where judgment matters and predictable everywhere else. I’d also version those checks as the workflow evolves.
exactly this, "let the model discover a rule once, then promote it into a validator" is a cleaner way to say what I meant. the regression example is the part I'd add detail on, once a rule gets promoted, I keep the original failing case that led to it as a permanent test, so if the rule ever gets edited later, you immediately know if you broke the thing it was written to catch in the first place.
Interesting take. Would you still recommend this approach to someone starting today?
Interesting take. Would you still recommend this approach to someone starting today?
Nice, this makes a lot of sense. What's been the most surprising part of it so far?
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?
Nice, this makes a lot of sense. What's been the most surprising part of it so far?