Ben Holmes

We're really just trying to give people the primitives to figure out what workflows are actually useful.

And I think some of the early wins have definitely been using the scheduler to handle all of these cleanup tasks that you don't want to trigger manually yourself.

All right.

I think that's a very normal use case.

It's actually matching what a lot of our internal teams are doing as well.

I myself, like on the developer experience side, we've been using these Oz agents, not for code, but for like going through our community mentions and suggesting like, should we engage with this person?

And if so, what should the reply be?

And if we want those replies to improve,

Maybe it makes a pull request to improve its own skills on how it drafts those replies.

So we've set this thing up in a very pluggable way where it's not actually writing any code.

It's really just waking up.

It's looking at all these mentions and it's deciding what to do.

Similar to enrichment.

It's just like these agents are super useful for connecting one tool to another tool and doing all the work in the middle.

If you want it to write code, you certainly can.

Yeah, I mean, I will say that the minimum is quite low because I do feel like echoing what Zach said, some of the most powerful automations we built so far have not come out of the engineering team.

They've come out of creative, marketing, developer experience, support, all of these other areas that need some way to automate their work.

And we've kind of made the interface to set up these Oz agents very agentic, even down to creating an environment to spin these things up.

You can talk to the agent and craft the environment with it.

Like, oh, I need an environment.