Obsvra

Back to trackLesson 3 of 3

Agents 3: Ask Instead of Write

You don’t need to already know SpiceGrinder’s model format, or even which statistical distribution fits your data, to get a working model out of it. You can just describe the shape of the data you want and let your agent do the rest — and what comes back is exactly the same kind of plain-text file Lesson 2 already showed you how to verify.

The initial prompt

Here’s a prompt we gave our own agent, word for word:

“I need realistic test data for customer support ticket response times, in minutes. Most tickets get resolved quickly, but there’s a long tail of tickets that take way longer to close. I want 500 example response times.”

Nothing in that sentence names a component, a parameter, or even the word “distribution.” That’s the point — you’re describing the shape of the problem, not the solution.

What came back

<dataset seed="7">
  <root node="ResponseTime"/>
  <nodes>
    <Lognormal name="ResponseTime" mu="3.0" sigma="1.0"/>
  </nodes>
</dataset>

The agent read “most tickets resolve quickly, but there’s a long tail” and recognized that as the textbook shape of a lognormal distribution — bounded below by zero (a ticket can’t have negative response time), clustered toward the low end, with a right tail that can stretch arbitrarily far. mu=3.0 puts the median around 20 minutes (not the mean — that’s the point of a skewed distribution); sigma=1.0 gives it room to stretch.

Run it, and the tail isn’t just theoretical, it shows up in the data:

71.02633549316906
32.3160634601662
40.59800764761874
38.50550142453533
12.719896368104216
14.424868392439688
6.076228390371773
13.906449831392976
...

Across 500 rows: median 22.6 minutes, mean 34.9 (pulled up by the tail, same as real support data usually is), and a genuine outlier at 302.3 — a ticket that took five hours to close. That’s what a lognormal tail with these parameters should produce, and it fits the “way longer to close” the original problem statement described.

It’s still just a file

It doesn’t matter that you used an agent and a prompt instead of hand-typed XML changes; the model file is the result either way. It validates the same way (ModelValidatorApp — VALID (0 failures)), runs the same way, and reproduces the same way: use the same seed and get the same 500 numbers on any machine, whether or not the agent that wrote it is anywhere nearby.

If you want to see exactly why the agent reached for Lognormal and not, say, Gamma (a real alternative for this same shape), you can ask it — or check both against the catalog yourself, since neither one is invented for the occasion.

That last part matters more than it sounds like it should. The instructions this skill follows are explicit that a component has to actually exist, with its actual parameters, before it’s allowed to end up in your model — a plausible-sounding name that doesn’t exist just produces a file that won’t load.

You can check this the same way you’d check any other claim in this series: read Component-Library-Reference.md or use the library command and confirm Lognormal is real, Free tier, and takes exactly the two parameters (mu, sigma) that showed up in the file.

As a side note, if you are running as a Pro tier user and your agent still can’t find a component that matches what your problem needs, it can help you design a custom component to plug in.

Asking again

The ask doesn’t have to be one-and-done, either. Iteration is definitely part of the process. “Actually, split that into weekday and weekend response times — weekends should be slower” is a perfectly good follow-up, and what you’d get back is a small, readable diff against the file above, not a new opaque blob:

<nodes>
  -
  <Lognormal name="ResponseTime" mu="3.0" sigma="1.0"/>
  +
  <Mix name="ResponseTime">
    +
    <input name="Weekday" weight="5"/>
    +
    <input name="Weekend" weight="2"/>
    +
  </Mix>
  +
  <Lognormal name="Weekday" mu="3.0" sigma="1.0"/>
  +
  <Lognormal name="Weekend" mu="3.6" sigma="1.1"/>

This also reinforces the point that our plain-text models really are simple to maintain: a clean, simple diff shows you exactly what changed, and it’s easy to follow.

What to verify

  • The component is real, not invented: check whatever generator/filter/business-object name shows up in the file against Component-Library-Reference.md yourself — the skill’s own instructions require this, and a fabricated name simply won’t load.
  • The parameters match what you asked for: if you said “most tickets resolve quickly,” the median should actually be low relative to the tail — run it and check the numbers, don’t take the shape on faith.
  • It’s Free tier unless you said otherwise: unless you’ve confirmed Pro access, nothing here should need it — Lesson 1 already told you how to check. If your problem does truly require Pro level components, your agent will determine that and tell you why it recommends Pro for your problem.
  • You can always drop into hand-editing: asking is a starting point, not a lock-in. Once created, the file is an artifact you’re free to do with as you wish.

If an ask ever produces a component that turns out not to exist, or parameters that don’t actually mean what the agent claimed — tell us. Same if it tries to push a Pro solution on you when a Free one should exist.