Ave Gatton

Fine and good for a prototype to see what level of utility you can get out of the agent infrastructure.

Do that quickly, do that fast, rapid prototype, develop quickly.

Then the hard problem becomes when you put that into production, you need to find a way to implement these secure patterns as much as possible.

So instead of just going and talking to the database, now you're asking like yes, no questions, and you have a secure model that, or you have a untrusted model that goes and accesses the database and can only return yes, no answers, etc.,

So you're separating concerns there, and then you're wrapping things in guardrails to make sure, oh, this is topically relevant.

Like, I'm not being asked to, I don't know, generate limericks or do some weird stuff that has nothing to do with, say, the finance task that I know I'm supposed to be working on.

That'll mitigate some of these sort of more naive attacks.

All of that is what organizations should be doing, what businesses should be doing as they move into production.

And then you iterate.

You go from there.

You try and improve the performance to gain again what you had in your POC.

But that's what I would recommend.

I think that having an eye, if you can,

move the security into the design process as quickly as possible after the POC so that you have a better sense of how you can create a secure agent and what the performance of that secure agent will be.

I think often you'll find that adding all these layers of security doesn't actually impact performance too much.

Typically, what people are looking for with agents now is raw ability as opposed to latency.

I rarely come across a scenario where people are like, oh, this is taking too long.

Almost everyone building with agents wants the results to be good more than they want.

They want a slow, good result versus a fast, bad result.

A fast, bad result, you might as well not have the agent at all.