Building an agent

Agents in the sidebar, then Create Agent. The builder is one long page with a Test panel beside it, so you can try the agent as you build it.

Or just ask in a chat. Describe the agent you want ("create an agent that checks the news every morning at 7 and writes me a summary") and Asteria drafts it for you. You get a card showing the name, the instructions, the tools and the schedule with its next run, and nothing is created until you approve that card. What you end up with is an ordinary agent: you can open it in this builder afterwards and change it like any other.

Most agents need three things: a name, instructions, and maybe a collection. Everything else is there when you need it.

Name and description

The name is what you and your colleagues type after @, so keep it short and specific. Brand Voice Check beats Marketing Assistant v2.

The description says what it does. Colleagues see it on the agent card, so write it for them rather than for yourself.

Underneath the name you will see an identifier like brand-voice-check-a1b2c. That is the agent's permanent handle, used by the API. It does not change when you rename the agent.

Instructions

The most important box on the page, and the one people under-invest in. Up to 5000 characters.

Write it as a brief for a competent new colleague. Cover:

Who it is and who it serves. "You check marketing copy for a B2B fintech selling to finance directors."

What good looks like. "Confident, plain, specific. Short sentences. No superlatives."

What to avoid, concretely. "Never use: revolutionary, seamless, game-changing, unlock. Never promise outcomes we cannot evidence."

What to do when unsure. This is the one everybody forgets and it is worth more than the rest. "If the claim is factual and you cannot verify it from the collection, flag it rather than rewriting it."

The shape of the answer. "Reply with the corrected copy first, then a short list of what you changed and why."

Vague instructions produce vague agents. "Be helpful and professional" tells it nothing it was not already doing.

Tools

What the agent is allowed to do. Add tool opens a catalogue grouped by source:

Built-in capabilities, offered as bundles:

• Web Search: search the internet and fetch the contents of a URL
• Sandbox: run code, compute over data, produce charts and files
• Documents: create and edit documents, decks and spreadsheets, with version history
• Diagrams: draw and edit flowcharts and architecture views

Connected services, if your organisation has enabled them and you have linked your account: Gmail, Google Calendar, Drive, Docs, Sheets, Slides.

Some tools pull in others they depend on, and the catalogue tells you ("Also enables…"). A tool added that way is marked so you know why it is there.

You can also override a tool's description to tell this agent when to use it. Leave that alone unless a tool is being used at the wrong moment.

Knowledge

Two different mechanisms, and the difference matters.

Pinned collections

Collections the agent always searches, without anyone naming them. This is the payoff: in an ordinary chat you have to name the collection, and an agent with pinned collections does not.

Pin the collections the job always needs. For a large body of documents, this is the right tool.

Uploaded files

Files whose content is placed directly into the agent's context, every single turn. Not searched: present.

Use this for short, always-relevant reference material: a one page style guide, a glossary, a decision tree. There is a token budget shown as you add files, and a size limit of 10 MB each.

The rule of thumb: a handful of pages, pin them as files. A pile of documents, put them in a collection. The app says as much when you get close to the line, because files eat context that could have been used for your actual question.

Skills

Procedures the agent can load when they are relevant, rather than carrying them in its instructions all the time. See Skills.

Attach the ones this agent's job involves. They cost nothing until used.

Sub-agents

Other agents this one can hand work to, up to ten. Each gets a delegation hint telling the parent when to use it.

Delegate to Data Analyst when the question needs figures computed from a spreadsheet.

There are two shapes worth knowing, and they suit different sizes of problem.

One agent that occasionally hands off

Your agent does its own job and delegates one specialised step. The brand voice agent that hands a data question to an analyst.

Reach for this when a job is mostly one thing with an occasional detour.

An orchestrator with a team behind it

For a genuinely complex job, build it the way you would staff it. Several specialist agents, each narrow and good at one thing, with only the tools and collections that thing needs. Then one orchestrator agent that is your entry point in the chat, whose instructions are mostly about which specialist to call when.

For a monthly competitor report, that might be:

• Market Researcher: web search only. Finds and summarises what competitors published.
• Data Analyst: sandbox and the metrics collection. Computes our numbers.
• Report Writer: the documents tools and the brand collection. Turns findings into the deliverable.
• Competitor Report (the orchestrator): no tools of its own to speak of. It knows the sequence, calls each specialist, and assembles the result.

You only ever talk to the orchestrator.

The reasons this beats one large agent:

Each specialist has a short, sharp brief. A single agent covering all three jobs needs instructions long enough that the important rules start getting lost.

Tools stay scoped. The researcher cannot write documents and the writer cannot browse the web, so neither wanders into work that is not theirs.

You can fix one part without touching the rest. The writer producing dull prose is a change to one brief.

The specialists are reusable. Data Analyst can sit under three different orchestrators.

The cost is real: every hop adds time and money, and a badly written delegation hint means the orchestrator calls the wrong specialist or does the work itself. So write the hints as decision rules, not descriptions:

Delegate to Market Researcher for anything requiring current information from outside the company. Do not attempt to answer from memory.

Delegate to Report Writer only once the findings are settled. Never ask it to gather anything.

When not to

Most agents should not have sub-agents at all. One well-briefed agent beats a committee, and if you cannot say in a sentence why a step needs its own agent, it does not.

Triggers

A schedule, so the agent runs with nobody watching. Add trigger, then pick a frequency:

Every day, Every weekday, Every week, Every month, or Custom (cron) for anything else. Set the time and your timezone.

Each trigger shows its last run and next run, and can be switched off without deleting it.

Output goes to the agent's Trigger output thread, reachable from the sidebar. It is read-only, but you can select any text and forward it into a normal chat.

Default model and temperature

Default model applies to scheduled runs. Leave it empty and it uses your default.

Temperature overrides how varied the responses are, and is off by default (it inherits your personal preference). Turn it down for anything factual and repetitive, up for brainstorming. Most agents never need it.

Suggested prompts

Starter questions shown when someone opens a chat with this agent. Purely for the humans, and disproportionately useful on a shared agent: they teach a colleague what the agent is for in the two seconds before they type something vague.

Status and the danger zone

Status switches the agent Active or Inactive. Inactive keeps everything but takes it out of circulation, which is the reversible way to retire something.

Delete agent is permanent.

Testing as you go

The Test panel on the right talks to the agent with its current configuration, including unsaved changes to instructions. Save first, then test, then adjust.

Test the awkward cases, not the easy one. Give it something outside its remit and see whether it declines sensibly. Give it something ambiguous and see whether it asks or guesses. That is where a weak brief shows.

Usage

Once an agent is in use, its Usage section shows how often it is invoked, by how many people, and when it was last used. Useful for deciding whether a shared agent has landed or quietly died.