Core Concepts

The InvesTeam pipeline is built on four ideas: a Master Investment Brief, an AI investment committee, a session that threads them together, and a submit-then-poll model that makes every stage asynchronous. Learn these four and the rest of the reference reads plainly. Each is defined once, here, the same way the product and the marketing glossary define it.

What is a Master Investment Brief?¶

A Master Investment Brief is the structured analysis mandate distilled from a free-form investment question — it defines what to analyze, not what to buy. When you submit a question, InvesTeam's analyst frames it into a brief: the subject, the thesis to test, and the questions worth answering. The brief is the foundation the rest of the pipeline runs on.

Producing a brief can take one round trip or two. If the question is ambiguous, the brief comes back needs_clarification with questions for you to answer; once answered, it settles to completed. If the question is off-mandate — not an investment question — the brief is rejected with a respectful explanation. See the Briefs reference.

What is an AI investment committee?¶

An AI investment committee is a purpose-built roster of specialist AI members assembled for one specific mandate. Rather than a single model answering, the committee assigns research tasks to members chosen for the brief's subject, and they deliberate. You convene a committee over a completed brief; the result is a plan (the roster plus its tasks), an execution you poll, a transcript you stream, and a final synthesized analysis.

The committee is analysis, not advice. It produces findings for you and your users to weigh — never a directive to act. See the Committee reference.

What is a session in InvesTeam?¶

A session is the single thread that ties a whole run together, identified by one session_id. That id co-keys every stage: the brief, the orchestration (the committee plan), the execution, the transcript, and the final analysis all share it. You get a session_id back from your first POST /api/v1/briefs and use it for every read and every subsequent submit in that run.

Because one id threads everything, re-entering a run is straightforward: fetch the furthest stage that has produced output and you have re-hydrated the whole session. Listing a principal's sessions returns each one's id, title, and status.

How does the pipeline fit together?¶

Every stage that does real work is asynchronous: you submit, get an id, and poll a matching read route until it reaches a terminal state. The full spine is one pattern repeated:

POST /api/v1/briefs                → session_id + status
  poll GET /api/v1/briefs/{id}       until completed | rejected
    (if needs_clarification) POST /api/v1/briefs/{id}/answers → re-poll
  POST /api/v1/orchestrations        → convene the committee
  poll GET /api/v1/orchestrations/{id}  for the committee + task plan
  poll GET /api/v1/executions/{id}      until completed | failed
    stream GET /api/v1/executions/{id}/transcript?after=<seq>
  poll GET /api/v1/analyses/{id}        for the final analysis

Why submit-then-poll rather than a blocking call? Because a committee run takes minutes, not milliseconds. A submit returns immediately with an id, and you poll at your own cadence — nothing holds a long-lived connection open. The async submit → poll model covers the pattern in full, and the Pipeline Walkthrough runs it end to end.