How Agent Outlook's two destinations differ, why the inbox is optional, and which one triggers an assembly line Task.
Without project mode Agent Outlook does one thing: send the email to an Agent Share inbox. That is the whole product, and it is the right shape when the add-in's job is simply "get this in front of an agent".
Project mode adds agentics.dk projects underneath. You pick a project first, and the destinations become project-scoped.
These are independent, and confusing them is the usual source of "why can't I see the stakeholder step".
| Flag | Where it lives | What it controls |
|---|---|---|
OUTLOOK_PROJECT_MODE | The add-in deployment's own configuration | Whether the project step exists at all, for everyone using this instance |
stakeholders | Per project, on agentics.dk | Whether that project shows the "Regarding" step |
So a project-mode instance can perfectly well show you a project with no "Regarding" picker. That project simply has the stakeholders module switched off. Turn it on in the project's settings on agentics.dk.
Posts the email as a share into one of the project's Agent Share connections. An agent watching that inbox sees it arrive.
This is the destination with a side effect worth knowing about. Posting into a project's share connection fires that project's outbound webhook, which creates a Task on the project's assembly line. That is usually what you want — "this email is work" — but it is a real, visible consequence, not a quiet write.
Files the email as an interaction against one or more of the project's stakeholders. It shows up on their activity line in agentics.dk with direction, timestamp, subject, body and attachment metadata, alongside every other interaction with that person.
Direction is decided by comparing the sender against your own signed-in address:
an email you sent is outbound, one you received is inbound.
This destination creates no task and fires no webhook. It is a record, not a request.
You need at least one destination. You do not need both.
A project can legitimately have no share connections at all — plenty of projects are a customer relationship long before they are an assembly line. Filing the email onto the stakeholder's timeline is a complete outcome on its own, and you can promote it to a task or route it into an inbox later from inside agentics.dk, once you know it needs to become work.
The practical consequence: the assembly line fan-out is opt-in. Picking an inbox is you saying "and this should become work". Leaving it empty files the email and stops there.
If you pick neither, Track is disabled — there would be nowhere for the email to go, and marking it as tracked would be a lie.
Interactions are keyed on the message's RFC 5322 Message-ID. Tracking the same
message twice updates one record rather than creating two, so a re-track after a
correction is safe.
Shares are not deduplicated the same way. Tracking, untracking and tracking again currently posts a second share — and, if an inbox is involved, creates a second Task. Untrack today clears the category on the message; it does not retract what was already sent.
Travels: subject, from, to, cc, bcc, body, the received timestamp, the
conversation id, the Message-ID, and attachment metadata (name, size,
content type).
Does not travel: attachment bytes. They are never extracted from Outlook and never posted anywhere. Nothing downstream accepts them, so extracting them would only inflate the request.
The project picker lists projects under your own handle. Projects where you are a contributor under someone else's handle are not listed yet.