Agent Center

Running missions

A mission is the step from “do this task” to “achieve this goal”. You state the goal, a lead agent breaks it into a plan, you approve the plan, a team of agents works through it, and at the end the lead hands you a completion report to sign off. Two control points always stay with you: the plan at the start and the completion at the end. This article walks the whole path, including everything that waits for your decision along the way.

On this page

Missions are the newest and least proven part of the Agent Center. The mechanics are fully built and safeguarded, but the number of missions that have actually run through is still small. For your first mission, pick a goal whose result you would review anyway, and a case where nothing critical happens. The field and send proposals further down have the least practice behind them.

Prerequisites

  • You need the “Manage missions” permission — without it you don't see the Missions view at all.
  • You need at least one active agent. If there is none, the page says so and points you to Agent Center → Agents.
  • Your lead agent needs the “Run mission” tool. Without it you can create the mission but not start it.
  • The participating agents need “Work mission tasks” so they work their delegated tasks themselves — plus “Send messages” if they are to draft messages.
  • If you want the mission to actually do something, you need a published template a case can be created from.

The lead-agent picker marks an agent without the “Run mission” tool as “not granted” and names the missing tool. Watch for it while creating — otherwise you only notice when “Start mission” doesn't work.

Step 1: create the mission

Under Agent Center → Missions you create one with “New mission”. It comes into being as a draft — until you activate it, nothing happens.

Goal
What is to be achieved. The required field and the most important text of the whole mission: the lead agent derives the template, the category and the tasks from it. State an outcome, not an activity — “The new customer is fully onboarded and has their access” leads to a better plan than “do the onboarding”.
Expected outcome
Optional. Describes what “done” looks like. Use it for acceptance criteria you want to measure the completion report against later.
Lead agent
The agent that breaks the goal down, puts the plan forward, delegates and finally writes the completion report. Exactly one per mission.
Linked case
Optional. The case in which the lead may create and delegate tasks — and only there, never organization-wide. Leave it empty and the lead creates one itself at start, from the template it chose.
Participating agents
Only these agents can receive delegated tasks in this mission. Save them with “Save participants”. An agent that is not a participant receives nothing — even if it is active in the organization.
Reviewer
A checkbox next to exactly one participant. That second agent reviews the plan and the completion before they reach you. Optional; without a reviewer the mission runs without this step.

If you link no case and the lead creates none either, it cannot create tasks and cannot delegate — the mission then serves pure planning. The interface points this out. It is a legitimate use, but rarely the intended one.

At most one mission works on a case at a time. If a case already belongs to a running mission, the picker marks it “taken” and shows which mission is handling it, with a link there. Only when you complete or cancel that mission does the case become free again. This is what keeps the same message from being prepared and sent twice.

Step 2: activate and start

A mission moves through five states: Draft, Active, Awaiting approval, Completed and Cancelled. “Activate” turns the draft into a running mission. If the linked case has meanwhile been taken by another mission, activation is refused with exactly that reason — including a link to the mission handling it.

“Start mission” then really hands the goal to the lead agent. It breaks it into a plan: a suitable published template, a fitting category if your organization uses them, and concrete tasks, each intended for a participant. While it works you see “The lead agent is drawing up a plan …”.

Nothing real has happened up to this point. The plan is a proposal, not a case. No case has been created, no task handed out and nothing sent.

Step 3: approve the plan — the first control point

Once the plan is ready it appears under “Approve plan”. You see which case it would start, which category it picked and which tasks it wants to hand to whom. You can still change the category before approving.

  • “Approve” puts the plan into effect: the case is created and the tasks are delegated to the participating agents.
  • “Reject” opens a field for a reason (optional) and discards the plan. The mission continues, but the plan is gone — you can sharpen the goal and start again.

If you named a reviewer, its verdict sits right on the approval card: “Looks good”, “With concerns” or “Not suitable”, each with its specific concerns. If you want to approve despite a “Not suitable”, bricksta asks once more.

The review is purely a second opinion: the reviewer changes nothing in the plan and blocks nothing — the decision stays with you. The review also draws on the reviewer agent's budget; if that is insufficient, the approval is still shown, with a note that no review was produced.

Step 4: let the team work

After the plan is approved, it isn't only the lead agent that acts. Every participating agent you gave the “Work mission tasks” tool works its assigned tasks on its own: it records its work result as a note on the task and completes it through its own execution permission.

The mission detail has a “Let the team work” button for this. It has the still-open tasks worked through — you can press it as often as you like. Afterwards the mission tells you what happened: that work was done, that there was nothing to do just now, or that something below is waiting for your decision.

Tasks assigned to a person — or to an agent you have not yet given “Work mission tasks” — stay open. That is not a fault but the boundary of autonomy. The completion report lists these tasks separately at the end.

If a run doesn't advance the mission although open tasks exist, the most common reason is a work run that took too long and was cut off. Press “Let the team work” again — or break the plan into smaller steps next time.

Reviewing field suggestions: a task's output fields

When a task has structured output fields, the agent doesn't simply fill them in — it suggests values. They appear on the mission detail under “Field suggestions for review”: per field the proposed value, which you can accept, edit or deselect. You have three ways out: “Approve values” accepts them, “Revise” sends them back with a reason, “Discard” ends it.

Sometimes the agent puts up not one suggestion but several complete alternatives — three topics with a key message each, say. A bar then sits above the fields: “Alternatives — pick one”. Tap one, see exactly its values below, and edit them as usual. Only the selected alternative is ever approved, never a mix of two: the parts of a suggestion belong together, and nobody would stand behind a pairing the agent never proposed. After approval the card says which alternative it became.

“Revise” is the way when the direction is right but the result isn't yet. You write one sentence on what should change — and on the next work run the agent puts forward a new suggestion that knows your reason. Repeat as often as you like; there is no limit. The reason is required: without it the agent would get the same brief as the first time and would have no cause to deliver anything different. While a task is being revised, the mission cannot be completed.

Approved values are not written immediately but at the next work run — through the same checks as for a person: required fields, visibility rules, field permissions. Only then is the task completed. If a visible required field is still empty, it stays open.

Fields reserved for a specific role are not filled by the agent — it doesn't hold that field permission. They are skipped and you enter them yourself as the role holder, so “who may fill which field” is preserved even during autonomous work.

Whether anything is proposed at all you decide per mission with the “Field output” setting. It has two positions: “Review” — field values are written only after your approval; this is the default. And “Automatic” — the agent writes low-risk fields directly, without you seeing them first. The mission then carries an “Auto mode” marker, and the values concerned are marked on the case as automatically filled.

Only switch to “Automatic” once you have seen across several missions what your agent actually proposes. Automatic mode is built and safeguarded, but not yet proven in practice — and it removes precisely the review through which you would learn this. A field filled automatically and wrongly only shows up on the case.

Reviewing send proposals: before anything goes out

When a task is about sending something, the agent prepares the message — recipients, subject and body — and sends nothing on its own. The draft appears on the mission detail under “Messages for review”, with the channel beside it: email, Teams or Outlook.

  1. 1Check the recipients. The agent proposes only from known contacts — case participants, members, merge fields; it invents no free-form address. You, by contrast, can remove recipients, add from members and contacts, or enter any email address.
  2. 2Read the subject and body and correct them where needed. Both are freely editable.
  3. 3Press “Approve & send” — or “Discard” if the message should not go out.

Approving is not sending. An approved message goes out the next time you press “Let the team work” — not at the moment you approve. And the schedule that keeps a mission running on its own never sends at all. Approve a message and then close the tab, and it sits there.

Teams reaches internal members only — the recipient selection is limited accordingly there. And the Teams feed shows just the subject as a title plus a link to the case; the message body is not displayed there, it stays in bricksta.

Before you approve a proposal going through Teams or Outlook: both routes are practically unproven from inside an agent run — for Outlook we know of no successful send from the application. The article Setting up agents explains what has to be in place per channel. Try each of them once with a harmless message to yourself before it reaches a customer. The email route is unaffected by this.

After sending, the mission reports the outcome. If messages went out it says so explicitly, even when others failed — a partial success is never swallowed by the problem. For failed sends you find the reason on the send card; if a delivery is hanging on a fault, the next run retries it itself.

If the mission says a send is hanging on a fault, please do not send yourself. The next run picks up that same message — it would otherwise go out twice. Only for “could not be sent” is manual work the right move.

For emails, bricksta later writes back whether the message actually arrived: “Sent to …” becomes “Delivered to …”, or, on a bounce, “Could not be delivered” with the reason — the send task is then reopened automatically and the responsible person notified. Teams and Outlook have no such feedback; there it stays at “sent”.

The approvals page: everything waiting, in one place

Besides the proposals on the mission detail there is the collective view Agent Center → Approvals. That is where agent actions originating from your templates collect — typically an email an agent wants to send, or an AI field fill. Each card names the kind of action, the agent and how long it has been waiting, and links to the case.

  • “Approve” carries the action out.
  • “Reject” skips it permanently — with an optional reason for the record. The case moves on without this step.

The list shows each person only the actions they are actually allowed to decide. If it is empty, nothing is open — not that you are not allowed to see anything. You can still grant individual approvals directly on the task itself; the collective view merely saves you the hunt.

Step 5: complete — the second control point

Once the tasks are worked through, the lead agent puts a completion report to you under “Sign off completion”. It describes what was achieved and separately lists what stayed open — tasks assigned to a person, for instance. Here too the reviewer's verdict sits alongside, if you named one.

“Approve” signs the completion off and the mission is completed; the linked case becomes free for other missions again. “Reject” sends it back — the mission continues and you can let the team work on. Independently of that you can end a mission at any time with “Cancel mission”.

As long as a send proposal is open, you cannot complete the mission. Decide it first — approve or discard — otherwise a prepared message would be left with nobody to decide it.

The same applies to “Cancel mission”: you cannot cancel either while a message is unresolved. The reason is the same — the team does not work on a closed mission, so an approved message would never go out. You have two ways out and the send card offers both: “Let the team work” actually sends the message, “Discard” takes the approval back. Only then can the mission be closed. If a delivery is in flight, wait a moment — after a few minutes it counts as stuck and can be discarded too.

Afterwards: what the mission learned

After completion the lead agent draws brief lessons from how it went — what worked and what didn't — and carries them into future plans. If that doesn't happen automatically, the mission detail has a “Reflect now” button.

You see the result in two places: right on the completed mission under “What was learned from this mission”, and cumulatively in the agent's profile under “What this agent has learned” (Agent Center → Agents). If nothing reusable came out, that is stated honestly rather than inventing an insight.

Deleting a mission

Missions you no longer need — a false start, an experiment, something long since done — can be removed at the bottom of the mission detail, under “Delete mission”. The mission disappears from the list along with its participants, pending approvals and suggestions.

Two safeguards sit in front of that: a confirmation, and then a short window. During it a notice at the bottom of the screen offers “Undo” (Ctrl+Z / Cmd+Z works too) — take it and nothing is deleted at all. Only once the window has passed does the mission really leave the database.

What stays: the runs and the costs this mission caused. They remain under “Runs & costs” and in the budget figures — so deleting a mission never changes a number you have already reported. What agents learned from it stays in their profile too.

A working mission (active or awaiting approval) cannot be deleted. Complete or cancel it first — then the delete button appears. That way ongoing agent work can never disappear with a single click.

When a mission gets stuck

“Start mission” does nothing
Usually the lead agent lacks the “Run mission” tool. Grant it under Agent Center → Agents → Tools and start again.
The run is denied
The budget gateway turned it away — inactive agent, missing tool or exhausted budget. The three causes and their respective ways out are in the article Budget, cost and runs.
“Nothing to do just now”
There is no open task an agent could work itself. Look at the case: most likely every open task is waiting on people — or on one of your decisions further down the mission detail.
A task won't close
A required field has to be filled on the case itself — assigning a person, for instance. Enter it there and the task closes on the next run.
The case can't be linked
It is already taken by another mission. The picker shows which one — complete or cancel it and the case is free again.

If you find yourself nudging the mission by hand every time, the next article is the right one: Keep working on its own explains the schedule that continues a running mission even when nobody has the app open — and what it explicitly does not do.