How it works
What happens between an event and finished work
Belowdecks works like an operating system for your processes. An event starts the work, an agent carries it out in a confined space, your company’s operator steps in at the planned moment and the agent finishes with a verdict.
The actors
Who acts in an instance, and where
Every explanation on this page names the actor involved. On the Horizon symbol, the operator sits above the line, the agents below it, end customers outside and the Belowdecks team behind the scenes.
- Step 1 of 4: Marc writes on your website and confirms his request. Who acts: Marc, End customer
- Step 2 of 4: The agents prepare the quote. Who acts: Agents
- Step 3 of 4: Julie answers from an email. Who acts: Julie, sales, Operator
- Step 4 of 4: The agents deliver and record. Who acts: Agents
Marc, End customer
Outside the mark,Writes in and confirms their own request
They write to your website assistant, send an email or fill in a form, and they never see the instance. The approval regime can let them confirm a card that concerns only their own request.
- Hello, I need a quote for three buildings.
- Yes, this summary matches my request.
Julie, sales, Operator
Above the line,Decides
The operator works in the instance, in the team space and from the signed links in their emails. They answer the agents’ questions and confirm the cards that commit your company.
- Answers from an email
- Confirms in the instance
Agents
Below the line,Works
Each agent works on your dedicated instance, in a confined folder, with its tools and limits. It prepares the work, presents it on a card or in a question, then ends with a verdict.
- Front-desk agent
- Quoting agent
Belowdecks team
Behind the scenes,Sets up and monitors
We install the instance, set up the agents, functions and connections with you, switch on confinement, then monitor how it runs. We never confirm a card on your behalf.
- Installs the instance
- Switches on confinement
- Monitors
The model
The six parts of how Belowdecks works
The first four describe a run and name who acts at each moment. The last two describe what surrounds it: improvement from week to week, and how each actor reaches the instance.
- 1
An event starts the work
The trigger is the event that starts the work: an email from an end customer, an article in a feed, a dropped file, a call from one of your systems or the scheduled time. It starts the agent in charge of that work, or a function when the work needs no judgment, and hands it the event’s data.
- 2
The agent works in its own space
It has a mission, skills (instructions written in everyday language), real tools, a time limit and a cost cap, both adjustable for each agent. It runs on an engine such as Claude Code by Anthropic, Codex by OpenAI or pi, works in its own folder on your dedicated instance, and the operator can follow every step live.
- 3
The operator steps in at the right moment
In a conversation, anything that commits your business shows up as a confirmation card addressed to the operator; an end customer can confirm a card that concerns only their own request. An agent started by an event can be set up to wait for the operator’s approval before it begins. If it’s missing information, it stops and asks the operator.
- 4
The run ends with a verdict
Every run leaves a log of its steps, the files it produced and its cost, and the agent declares its verdict: Delivered, Partial or Blocked. The operator can find any run again later with a search.
- 5
The instance improves
Every night, an analysis spots what snags, and every Monday the open insights arrive in the operator’s conversation, with a card to confirm when the fix is precise. Repeated work can move to functions, which run with no token cost.
- 6
Each actor has their own way in
The operator and your team work in the instance and the team space, end customers talk to your website assistant, and your other software goes through the REST API or the MCP server. The Belowdecks team installs and monitors the instance.
Triggers
What puts an agent to work
Each trigger starts an agent, or a function when the work needs no judgment. The operator can also start an agent by hand, from a conversation or from the instance, and your software can do so through the API.
-
A mailbox
Each new message in an IMAP mailbox starts a run, such as an end customer’s request or a supplier’s invoice. You can filter by sender, recipient or subject.
-
RSS or Atom feeds
Each new article in a watched feed becomes a task: trade press, public bodies, alert feeds.
-
A watched folder
A file added or changed in the folder starts the agent, which receives its path.
-
Webhooks from your software
Your software calls the trigger’s own address. The signature is checked, and filters set aside events that don’t concern you.
-
A schedule
Every Monday at 7 a.m. or on the 1st of the month, set on screen. Describe it in plain words (“weekdays at 8 a.m.”) and Belowdecks turns it into a schedule.
-
New rows in a collection
A request confirmed by an end customer on your website assistant, for example, can put the quoting agent to work.
The agent’s space
The agent’s tools and its confined space
Each agent is configured once with the Belowdecks team when the instance is set up: mission, engine, tools, limits. It then works on its own, within those settings.
Real tools
A terminal, the files in its folder, a headless web browser and the MCP servers that give it access to your software’s API.
Skills written in plain language
Your ways of working, written once and reused by the project’s agents: the tone of your replies, your filing rules, your checks.
Limits on every run
Every run has a time limit and a cost cap, with default values you can adjust for each agent. A run that reaches either one stops.
Confinement switched on and verified at setup
Each run sees only its own working folder on the server. The Belowdecks team switches this confinement on and checks it when each instance is set up.
Secrets in an encrypted vault
Passwords and keys are encrypted at rest, redacted from logs and never exported. The API can store them but never read them back.
Agents that share the work
An agent can start another one or split a task across parallel runs. A builder agent can prepare the agents that will carry on its work; unless you have given the project that autonomy, they arrive switched off and the operator decides whether to switch them on.
Cards and questions
The operator steps in when their approval matters
The agent is set up not to act alone on anything that commits your business. In a conversation, it first presents a card, a pre-filled form you can read in a few seconds. When an event starts it, it can wait for the operator’s approval before it begins, or stop to ask them a question.
What runs is what the person read
The card holds the exact values the action will use. Depending on the action, the person confirming can correct a field first; declining runs nothing.
The approval regime sets who confirms
An end customer can confirm only their own request, when the regime allows it. Anything that commits the company goes to the operator, or to another person on your team who gets the link by email. Agents prepare the card, and a conversation can only make the regime stricter.
One gesture from an email
The operator confirms a card, approves an agent’s start or answers its question from a signed link, without signing in. The link opens a confirmation page before anything happens.
The questions inbox
When it’s missing information, the agent drops its question in the questions inbox. The operator answers in the instance or from an email, your software through the API, and the agent picks up where it stopped.
Emails sent to your customers
When an agent writes to an end customer or a supplier, the email goes out through a sending function or a mail connection set up with you at installation. The agent can be set up to ask the operator before each email goes out.
A dress rehearsal before going live
The agent works on real data with its real tools, in a throwaway folder, with the instruction to describe binding actions instead of carrying them out. The operator reads a report of what it would have done before switching it on.
For the operator: send Atelier Lavoie a reminder for invoice 2041?
- Client
- Atelier Lavoie
- Invoice
- 2041, overdue since September 30
- Tone
- Friendly, no late fee
Choices offered on the card: Edit, Confirm.
Over time
The instance gets better, and repetitive work can move to functions with no token cost
Every run leaves a trace. Those traces are used to fix what fails and to hand repeated work to code.
-
Insights on what snags
Every night, an analysis without AI spots repeated failures, timeouts, unusual costs and forgotten approvals. An AI analysis also looks for the root cause of a problem, agent by agent, and recommends a fix.
-
A review every Monday, in the operator’s conversation
Open insights arrive in the operator’s conversation. When the fix is precise, such as extending a time limit or setting a cost cap, a card shows it to them: they read it, then apply it in one click. Only a time limit that is too short can be extended without waiting, when the diagnosis is certain.
-
Functions that redo the work without a model
A function is named code (bash, Python, Node or PHP) that runs with no token cost. After a successful mission, an agent can hand the mechanical part to functions. They are first tried on their example sets, and if one fails, the agent takes over.
-
Repeated tasks spotted
When an agent repeats the same steps in the same order, the analysis flags it. A draft function can then be created, completed and tried, often with the Belowdecks team. The operator then confirms on a card that it can go into service; the instance replays the trials first and refuses to switch it on if one fails.
-
An agent that proposes changes to its mission
An agent can propose a change to its own instructions, which the operator accepts or declines. The operator can also ask the instance assistant for a change, and it shows them the before and after on a card.
-
A monthly report on the 1st
On the 1st of the month, the operator receives an email summing up the month: runs, verdicts, cost, tokens, questions handled or still waiting and open insights, with a breakdown by agent.
Ways in
The operator, your team, your end customers and your software each have their own way in
The same agents, collections and cards serve everywhere; rights depend on who is talking to the instance.
-
Team space
Screens built for the operator and your team: a conversation, a collection’s data, action buttons, runs, waiting questions.
-
Rights by group
Each group has its rights in a project: chat, read or edit data, follow runs, start an agent, call a function, answer agents.
-
Your website assistant
One script tag adds it to your pages. Each end customer gets their own conversation for 12 hours, and only the domains you allow can open it.
-
End customers’ cards
By default, an end customer’s card goes by email to the operator. You can hand it to another person on your team or let end customers confirm a request that concerns only them.
-
REST API
Your systems start agents, follow their runs and read collections. The OpenAPI 3.1 specification describes every route.
-
MCP server
Assistants and agent frameworks that support MCP use the instance as a tool server: start an agent, answer a question, query a collection.
Questions about how it works
Do I need to open a conversation for the work to happen?
Triggers start agents without anyone writing to them: an email, a file, a schedule, a webhook. The operator uses the conversation to direct agents in plain language, adjust their settings and confirm their cards.
Who is the operator, and can there be more than one?
The operator is the person in your company who runs Belowdecks. They receive the agents’ questions, approve their work and decide what goes out.
Several people on your team can share this role. Notification rules, which can target one agent or one project, and each group’s rights decide who receives which questions and who can confirm what. For your website assistant, the address that receives cards is chosen at setup.
Who confirms the card when the request comes from an end customer on my website?
By default, the card goes by email to the operator named at setup, and the end customer sees that the request is waiting for approval. You can instead hand it to another person on your team, who receives the confirmation link, or let end customers confirm a request that concerns only their own data, and their part ends with that confirmation.
What happens when an agent doesn’t know what to do?
It stops and drops its question in the questions inbox. If a notification rule is in place, the question also reaches the operator by email, with one button per answer when it’s a simple choice. Once the answer is given, the agent resumes in the same session, with all its context.
An unanswered question doesn’t hold up other agents. The operator can also dismiss it, in which case the agent is not resumed.
Can agents act in my software?
Yes, when your software offers an API or an MCP server. The Belowdecks team configures the connection at setup, and the access keys are kept in the secrets vault. Your software can also start an agent by webhook or write to a collection through the API. Actions that commit your business are set up to wait for the operator’s confirmation.
What language does Belowdecks work in?
Agents write in the language set in their instructions, French or English. Your website assistant answers end customers in the language they use.
How do I know what the agents did?
Each run has its log: steps, files produced, cost and the verdict the agent declared. An activity feed shows the operator what is running, what failed and what is waiting for a person, and the monthly report reaches them by email on the 1st.
Next step
Let’s see which process your agents could take on
The diagnostic starts from your actual work and picks, with you, a first cycle, a first trigger and the person who will act as operator. You then receive a written plan.