Three diagrams for how context flows through Gloo360 OS.

The framework every data flow follows, the first bucket we're building applied to it, and the folder layout each client sits in. Read in order: shape, then use case, then storage.

Owner: Architect agent (Gloo360 OS) · Date: 2026-04-23 · Status: DRAFT v0.5 · Task: task_0423-01 · Parent: task_0406-15

Purpose

Gloo360 leadership asked for the Gloo360 OS context-gathering pipeline in a viewable format. Two diagrams do the heavy lifting, in sequence.

The framework. The four-stage pattern that every data flow in the system follows. Once you understand this shape, you understand the whole thing.
The use case applied. Portfolio Health, the first bucket we're building. Shovel-ready because the stabilization agent, HubSpot MCP, and Google Drive access are already in place. Shows how the framework lands in reality.

Audience: Gloo360 leadership. Design intent: Mermaid is the portable source format; renders directly in Notion, GitHub, Slack canvas, and Cowork artifacts. Stills can be rendered from either diagram for slide use.

The Framework: four-stage pattern

Every Gloo360 OS data flow, whether workforce, portfolio health, or vendor management, follows this same four-stage shape.

Diagram 1.Figure 1 — The four-stage pattern. Solid arrows: forward flow. Dashed arrow: corrections feedback from the output review surface.

How to read it

Ingest is dumb. Collectors capture, they don't analyze. That makes them replaceable as MCPs evolve or source systems change, e.g., Rippling or any future HRIS, HubSpot or any future CRM. Only the collector changes; the rest of the pipeline doesn't notice.
Normalize decouples sources from reasoning. The orchestrator never touches HubSpot or Monday directly; it reads markdown. Swap a source, the reasoning layer doesn't notice.
Reason uses a two-pass pattern. Pass 1 summarizes per client (5 to 10 lines each). Pass 2 reasons across the summaries. Context stays lean as the portfolio grows from four clients to 40.
Output carries breadcrumbs. Every claim links back to the source markdown file. No black boxes: anyone reading a summary can trace any fact to its source.
Three audiences, stage-gated. Output summaries push to Gloo360 Leadership (strategic view: health, risks, ARR), Capability Teams (execution view: stabilization plans, QAPs, resource needs), and Account Teams (relationship view: CSM status, expansion signals, account health). Each audience gets the slice relevant to their decisions.
Corrections close the loop from the output. When a review happens against an output summary and an error is spotted, corrections are captured against the doc and flow back to the normalize layer via knowledge/gloo360_os/corrections.md. The next run incorporates them.
This pipeline produces context, not action. Forge workflows and staff decisions are a separate downstream layer. What this framework shows is how context gets produced and summarized into audience-specific views; what people (or Forge) do with those views lives in the action layer and is out of scope for this diagram.

The Use Case Applied: Portfolio Health

The first bucket we're building. Concrete end-to-end flow showing how the framework above lands in reality.

Diagram 2.Figure 2 — Portfolio Health applied to the four-stage framework. Sources converge on a single collector, which writes one file per client; the orchestrator reasons across those files into one summary routed to three audiences.

Why Portfolio Health goes first

Stabilization agent already tracks per-client health (RAG, ARR, SOW phase, risks) for the clients it currently owns stabilization plans for.
HubSpot MCP is already connected, giving deal and revenue data today.
The existing Portfolio Health spreadsheet lives in Google Drive, readable via Drive MCP today.
Per-client knowledge folders already exist (profile.md, timeline.md, org_profile.md, and more). The collector's job is to add or refresh health.md in each folder, not seed from scratch.
Leadership's most pressing pain point: "give me one view of all Gloo360 clients without asking anyone."

How the per-client folder works

Every client has a folder under knowledge/gloo360_clients/CLIENT/ with the same standard file set (profile, health, org_profile, timeline, qap_current, workforce, systems_log, relationship, qa_review, vendors/). Each file has a single owner and schedule. That keeps writes clean and prevents drift. The Portfolio Collector writes to health.md only; Workforce and Vendor collectors (the next two buckets) write to workforce.md and vendors/*.md respectively.

Live example: ABS Notion knowledge base. Per Gloo360 leadership direction (week of Apr 20), the ABS Notion knowledge base that shipped Apr 22 is the "first activation step" for Gloo360 OS — a per-client knowledge-layer instance already operational for one client. It proves the per-client shape in this diagram can stand up in a real engagement before the portfolio-wide collectors are fully automated, and it's the template the other client KBs will follow.

Data source status

Status	Source	Notes
✓	HubSpot	Connected via MCP today
✓	Per-client markdown folders	Exist today for every Gloo360 client
✓	Google Drive	Connected; can read the Portfolio Health spreadsheet once shared
!	Account team hub	Needs Drive sharing or manual seeding
!	CSM knowledge	Manual capture via Slack monitoring or a structured intake form

Operating details

Dimension	Value
Replaces	Manual portfolio review prep before every Exec Steering meeting
Schedule	Weekly collection; on-demand summary generation
Gloo360 Leadership	Strategic view: RAG status across all clients, ARR at risk, renewal windows, top 3 risks
Capability Teams	Execution view: which clients need capability work, where stabilization plans are off-track
Account Teams	Relationship view: expansion signals, CSM-owned risks, satisfaction trends

How the other two buckets follow

Workforce and Vendor Management reuse this same shape. Sources change, the collector changes, the specific file in the per-client folder changes (workforce.md instead of health.md, vendors/VENDOR.md instead of health.md), but the orchestration pattern and output format stay the same. That's the value of Diagram 1: the framework is what we're proving, and Portfolio Health is the first proof.

Per-client folder structure (detail)

Every Gloo360 client folder follows the same standard layout under knowledge/gloo360_clients/CLIENT/. Files are grouped by role: foundation context (read by collectors, maintained by humans) and bucket outputs (one file per data bucket, written by its collector).

Diagram 3.Figure 3 — Per-client folder. Foundation files are read-sources; bucket outputs are write-targets owned by exactly one collector each.

How to read it

Foundation files are read-sources. Collectors read them for context when producing their bucket outputs. Humans maintain them, sometimes with agent assistance. They change slowly.
Bucket outputs are write-targets. Each of the three data buckets has exactly one file it writes to per client. Single owner per file, single schedule, no drift. Today the Portfolio Collector writes health.md; the other two are planned and will follow the same pattern.
The vendors/ subfolder holds one file per vendor. Because a client typically has 5 to 15 vendor relationships, each gets its own file under vendors/ rather than cramming everything into one vendor.md.
Scale of what's on disk today. One folder per Gloo360 client × this structure. Not all files are populated for every client yet; that's a fill-in-over-time condition, not a structural one.

Source material

agents/architect/deliverables/Gloo360_OS_Agentic_Architecture_Proposal.md — v2 architecture, source of both diagrams.
knowledge/strategic/gloo360_os_vision.md — three-bucket framing, stage-gated pushouts concept.
tasks/active/task_0423-01.md — this task (source).
tasks/active/task_0406-15.md — parent task (Gloo360 OS 80% proposal).