Build agents where your apps already live

Agents are easy to demo and hard to put into production. The model loop is a few lines of code. The work is everything around it: somewhere to run it, a safe place for the model key, memory for each conversation, and a way for IT to see what’s running. Teams end up standing up a separate agent platform for that, or shipping without it.

Now in Helix, the agent lives in the app it serves. It’s defined in the app’s code, deploys with it, and works through the actions the app can already take. When the app goes live, the agent goes live with everything in place.

What that gives the team building it:

• Nothing new to stand up. The agent ships in the same deploy as the app, and any function or schedule in the app can call it. There’s no separate agent service to host.
• Claude can build it. Every new Helix project already teaches the AI assistant how to write agents and their tools, so a working agent is a prompt away.
• Helix runs it. It drives the model, runs the app’s actions against its connected services, and remembers each conversation, kept separate per user if you want. The model key is managed by Helix and never sits in the code, and each run stops at a step limit so a loop can’t run away.
• A person signs off when it matters. Any action can be set to wait for approval, and the agent picks up where it left off once someone answers.

What it gives IT:

• Every agent in sight. The project’s Agents tab lists each live agent, its model, its tools and which of them need approval.
• Every run in the logs. Each agent run and every tool call it makes shows in the project’s logs, under the request that started it.
• Every change on the record. An agent only changes when the app is deployed, and each deploy that adds or changes one lands in the activity trail.

So a team can give an app an agent without building a platform for it, and IT can say yes because the agent lives where IT already looks.

An example

IT gets access requests all day, and they almost never arrive as a tidy form. Here’s one going through an agent in the IT team’s request app.

1. Someone asks in plain words

Dana Lee starts Monday in FP&A. Can she have the same access as Sam Ortiz?

There’s no app or role in it. It only makes sense to someone who knows who Sam is and what he has.

2. The agent does the legwork

The agent finds Dana and Sam in the directory and reads Sam’s access: viewer on Looker and Adaptive Planning, editor on NetSuite. It lines up the same three roles for Dana. That’s the part of the ticket that usually sits in a queue, done in seconds.

3. It asks before it changes anything

Granting access is a write, so the team set that action to need approval. The person on the IT desk sees all three grants together, with who, which role and why, and answers them in one go. The agent makes the grants through the app’s Okta connection and tells the requester what’s done.

4. IT can see it

The agent shipped with the app’s last deploy. It shows on the project’s Agents tab with its model and its three tools, and the run that handled Dana’s request is in the project’s logs, tool call by tool call. If someone changes what the agent can do, the deploy that did it is in the activity trail.

What else you could build

The pattern is an app that already has useful actions, plus an agent that decides when and how to use them:

• An ops request handler in an internal tool that reads a request, looks up the records across connected systems, and proposes the fix for someone to approve.
• A data hygiene agent in a RevOps app that reviews CRM records, finds duplicates and gaps, and queues the corrections for sign-off.
• An onboarding assistant in a provisioning app that works out which accounts and access a new customer needs, then sets them up step by step.
• A procurement agent in a finance app that matches vendor payments to their purchase authorizations and flags missing paperwork.

Before you build one

If the request is already a form, you don’t need an agent. A plain function is cheaper and does the same thing every time. Agents earn their cost when someone has to work out what a request means.

Agents work through tools. They act through the app’s actions and connected services, using the app’s credentials. They don’t search document stores, so a bot that answers from a knowledge base isn’t the right fit.

Conversations close after 30 days idle. On a deployed app using the platform’s session store, a conversation with no activity for 30 days is removed.

How to define tools and agents, call them, and set approvals is in the docs linked above. For why agents belong inside the apps IT already runs, read Run your agents where IT can already see them.