Create and configure an agent

Define the agent's job and owning team, then choose the model and tools it may use.

A custom agent works best when it owns a repeatable job. Its team sets the access boundary, while the model, instructions, tools, and sandbox determine how it does the work and what each session costs.

Video placeholder

Create a focused custom agent

Record the full agent form, a first session, and the settings changed after reviewing that result.

Make three decisions first

Don't begin with every tool and a page of instructions. Decide the job, owner, and model before filling out the form.

01
Give it one clear job
Name the result the team expects; a narrow job makes mistakes easier to spot and correct.
02
Choose the owning team
Choose the team that owns the work because that choice controls the agent's connections and resources.
03
Match the model to the work
Routine tasks belong on a fast, lower-cost model; spend more only when the job needs stronger reasoning or code work.

Create the agent

Open Agents, select Create agent, then add a short name and description. Choose the name people will search for, and write a description that distinguishes this job from the other agents in the workspace.

Create an agent

Image placeholder

The custom agent configuration form

Show Basics, Model, Instructions, Tools, Team, Sub-agents, and Advanced settings at a readable scale.

Choose a model for the job

New sessions use the model selected here by default. Start with a fast, lower-cost model for routine work; move to a stronger model when real results show that the job needs harder reasoning or code work.

Someone starting a session can still pick another model, so this setting should fit the agent's usual workload rather than every possible request.

Write instructions the agent can follow

Write the job and expected result first. Add another rule only after a real session exposes a repeatable mistake; long speculative prompts become hard to debug.

Role: State the work this agent owns and the result people expect.
Process: Describe its usual method, including when it should ask for help.
Output: Specify the contents and format of a finished result.
Boundaries: List actions that need confirmation or must never happen.

Give it only the tools it needs

Tools let the agent read files, change code, run shell commands, search the web, and ask for input. Switch off any tool that has no place in this job.

Team connections come with the agent, but switching off an optional connection here doesn't remove it from the rest of the team.

Understand tools, sub-agents, and sandboxes

Keep access with the owning team

Every agent belongs to one team and works only in that team's work. Give ownership to the group that will review the results, since the agent also receives resources approved for that team.

Learn how teams control access

Set the runtime for the workload

Use the default sandbox image for general work; choose the developer image when the job needs preinstalled developer tools. Start with the smallest size that fits the work, then raise its CPU, memory, or disk only after a session hits a resource limit. Larger sandboxes spend more credits per active minute.

Saving the form doesn't create a sandbox. Hivy waits until the agent starts a session.

Test one real task before automating it

Run one representative task for the team and inspect both the result and its cost. Fix the instructions or tool access before you put the agent into an automation.