One company brief can support three useful responsibilities if each produces a different decision artifact. Research identifies supported facts and gaps. Meeting preparation turns those facts into a conversation plan. Follow-up records what actually happened and prepares the next step. Reuse the evidence, not three copies of the same summary.
Source check: October 22, 2026. Everything about the company and outputs below is a clearly fictional worked example. It illustrates an operating design using documented Aurora concepts; it is not a recording of three agents running or proof of an automated handoff.
The single input packet
Harbor Materials, an invented company, is preparing for a conversation with an invented prospective partner. The founder supplies a small approved brief. Assigning fact IDs makes later corrections traceable without copying the entire brief into every output.
| Fact ID | Permitted packet content | Boundary |
|---|---|---|
| H1 | Harbor develops a packaging material for specialty-food suppliers. | Approved company description; no unsupported environmental claim. |
| H2 | A pilot is being discussed with one supplier. | Discussion is not a signed contract or revenue. |
| H3 | The current test report covers one specified operating condition. | No claim about untested conditions. |
| H4 | The partner asked about qualification requirements. | The actual requirements remain unknown. |
| H5 | The founder can share an approved nonconfidential overview. | The technical appendix is not cleared for external use. |
The packet also includes a source date, the approved overview and the intended meeting audience. It contains no private account credentials. A contact name mentioned in the brief still needs to be matched to the right record before any saved action.
Give each responsibility a different question
For this example, the founder can use three bounded requests manually. If named Aurora responsibilities are available in the account, the same division can guide their instructions. Connected sources, organization access and feature availability still need checking. A multi-section prompt alone does not create a team.
| Responsibility | Question | Distinct output | Stop condition |
|---|---|---|---|
| Research | Which claims can we defend, and what is missing? | Evidence and gap ledger using H1–H5. | No reliable source for a material assertion. |
| Meeting preparation | What do we need to learn in this conversation? | Question plan and permitted talking points. | Audience or purpose is unclear. |
| Follow-up preparation | What did people actually agree to afterward? | Source-linked decisions, proposed tasks and draft message. | No reviewed meeting notes or unclear commitment. |
Output one: the evidence and gap ledger
The research request produces a narrow conclusion: the brief supports the product description and the existence of a pilot discussion. It does not support “commercially proven,” “signed partner” or a general claim about performance in every condition. H3 needs the test condition stated whenever used.
The useful artifact is a short exception ledger: claim, source ID, permitted wording, missing evidence and owner of the next check. It avoids doing meeting preparation before the founder has resolved which claims can travel outside the company.
Output two: a conversation plan
The meeting request reuses H1, H4 and H5. It asks three questions: Which qualification tests matter? Who owns the approval decision? What information can the partner share about the next review step? It includes the approved company description and the limit on the technical appendix.
It does not reproduce the research ledger. It points to the ledger when a claim needs checking. The founder reviews the agenda and decides what to ask. The Investor Meeting Prep Skill is an existing playbook for an investor conversation; a partner meeting needs its audience and questions adjusted rather than relabeled as fundraising.
Output three: follow-up after new evidence exists
In the fictional meeting, the partner agrees to send a qualification checklist. The founder offers to send the approved overview after confirming the recipient. No one agrees to a paid pilot. The follow-up request uses those reviewed notes to prepare an owner/task draft and a short email draft.
The output keeps “checklist promised” separate from “checklist received.” It does not invent a due date or mark a paid pilot as committed. The meeting-to-CRM review packet shows how to review a durable change separately.
Keep the handoffs observable
| Transition | Mode in this example | Human decision and receipt |
|---|---|---|
| Brief to research | User-triggered | Founder selects the permitted packet and inspects claim gaps. |
| Research to meeting plan | Manual | Founder passes the reviewed ledger and corrects talking points. |
| Meeting to follow-up | User-triggered after reviewed notes exist | Founder confirms speaker, commitment, audience and proposed next step. |
| Draft to saved/sent action | Not performed in this example | Separate exact authorization and actual result check are required. |
A source correction should travel to every affected output. If H2 changes from a pilot discussion to a declined opportunity, mark the old research conclusion and agenda stale. Do not assume that changing one conversation automatically updates every prior draft or remembered fact.
A prompt that preserves the division of work
Use this single approved company packet in Aurora AI in Finta, Claude or Codex: [fact IDs, sources, dates, audience and disclosure limits].
Prepare only the responsibility I select: [research / meeting preparation / follow-up].
Research: return an evidence/gap ledger with permitted wording. Meeting: return audience-specific questions and source-linked talking points. Follow-up: use reviewed meeting notes to separate decisions, requests, accepted commitments and unknowns; prepare a draft only.
Reuse source IDs rather than repeating the whole brief. Show what changed since the prior artifact and which other outputs become stale. Never upgrade a discussion into a commitment or infer a missing date.
Do not create agents, connect sources, automatically hand off, save records, assign tasks, send or enable routines. Explain which handoff I must review next.Common questions
Do I need three agents?
No. Start with the smallest arrangement that works. One Aurora conversation and three reviewed requests can establish whether the outputs are useful before adding responsibilities.
How is this different from three summaries?
Each output serves a different decision: factual readiness, conversation design or follow-through. If all three repeat the same facts without changing the decision, remove the duplicated work.
Does sharing a brief share my private App accounts?
No. A role definition or shared artifact does not transfer private account access. Verify the actual user, source and permissions for each task.
Use the responsibility-plan library to choose a smaller starting recipe, then maintain the shared evidence with a source freshness register.