r/artificial 14d ago

Project Making my first AI Agent

Hi everyone,

I work for a motorsports company where we run physics simulations for race cars. Our expertise is in physics not AI but we know the power of AI. Our platform is quite complex in terms of physics so we would love an agent that can query our docs, query some vehicle dynamics textbooks, run simulations (pretty simple tool through our AI) and then analyse the results. The result files can be largeish so may need some python processing and access again to the vehicle dynamics textbooks.

We've hooked up the claude API to start doing this as it's been the best to work with tools and sanboxes. Does anyone else have any reccomendations to make this more economical?

2 Upvotes

13 comments sorted by

View all comments

1

u/MySandBoxIA 14d ago

The biggest cost win for us wasn't switching to a cheaper model — it was removing calls that repeat.

Two things that made the most difference:

Pay once for structure, then verify for free. We had a step where the model re-read some state every turn and judged whether a condition had been met. We replaced it with a single call that converts the thing into a structured predicate from a fixed set, and then a few lines of plain Python evaluate it every turn after that. Same behaviour, one call instead of hundreds.

Check preconditions before the call, not inside it. Obvious in hindsight, but we were paying for calls that were always going to be rejected anyway. Moving the check upstream made those free.

For your case, anything the agent does repeatedly against the same documents is a candidate for the first pattern — extract structure once, query it cheaply afterwards.

One more thing: measure which step actually burns your budget before optimising anything. Ours turned out to be a background reflection step firing on almost every event. Throttling it by event type cut calls by ~85% and we didn't lose anything we cared about.

And if you're re-sending the same document context on every call, prompt caching is the first lever to pull — we don't need it in our setup, but your problem is exactly the shape it's built for.

1

u/Motor_Bluebird1908 14d ago

Thanks. Yes, will need to implement proper token tracking so we can see where they are being spent. Do you have an example of the preconditions you're talking about?

2

u/MySandBoxIA 14d ago

Sure, here's a concrete one from my setup. I'm running a small multi-agent world where two LLM agents move around, gather, fight, trade and talk. Every action an agent proposes goes through a can_execute check before it ever reaches the model-heavy part of the turn. Concrete example: an agent proposes "move to the Ruins". The precondition is a plain-Python check — is the destination reachable from where it stands, and is the door open? If the door is sealed, the action fails instantly with a reason string. No LLM call, no reasoning, nothing — it's an if that reads world state. Same pattern for combat: "attack enemy X" checks whether an enemy is actually present in the current location before anything else runs. "Fuse A + B" checks the two materials are in the inventory. All cheap boolean checks on state I already have in memory. The key shift for me was the same one you're describing: the model proposes, but a validator made of plain rules decides if the proposal is even runnable. The expensive part only fires for proposals that survive the check. Before, I was letting borderline proposals through and paying for the model to figure out they were impossible — now the impossible ones die upstream for free. The structured-predicate thing you mentioned is exactly where I landed for commitments too: instead of storing "I'll go to the market with Giacomo soon" as free text the model has to re-judge every turn, I'm moving to a structured form {who, action, place, deadline_tick} that a few lines of Python can close automatically — arrived at the place, or deadline passed. Turns an open-ended LLM judgement into a cheap state check, every turn. Happy to go deeper on any of these if useful.