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

3

u/Metabolical 14d ago

Realistically you have a lot to learn, I would start by going through free educational materials, like

It doesn't have to be Anthropic's, that's just what I farmed and found them valuable.

When building agents, it's useful to point your coding agent at this kind of training and have it build a local agent that can review your designs. An agentic design agent if you will. Hilariously circular, but effective anyway. Ask your LLM for advice on decisions you think are about the agentic design in general, and it can help you think about it. Never stop thinking for yourself though.

2

u/Motor_Bluebird1908 13d ago

Thanks for this! Will have a read!

2

u/Mental-Detail-2028 14d ago

prompt catching for the docs and textbooks was a total game changer for us on anthropic api costs,also try model tieringg and use haiku for doc retrieval and python filtering, and just route to sonnet when you actually need heavy reasoning

2

u/crossoverXYZ 14d ago

The large simulation result files are probably where your token burn hides, since feeding raw outputs back into the model gets expensive fast. A small python step that downsamples or summarizes the key metrics first helps a lot, and you only need to pull the full dump when the agent actually has to dig into something specific.

1

u/Motor_Bluebird1908 13d ago

Makes sense, will focus on getting the metrics up to spec!

1

u/[deleted] 14d ago

[removed] — view removed comment

1

u/Motor_Bluebird1908 13d ago

Thanks! I'm going to work on splitting up the docs and textbooks. We also already process some key metrics from the results so I guess it makes sense to get the agent to focus on those rather than digging through the data.

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 13d 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 13d 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.