Workspace Context & Intelligence

Every workspace in Agency Hero builds context as you use it. After your first meeting, a few decisions and open questions land in the workspace. After ten meetings, you have a layered picture of what’s been decided, what’s at risk, what threads are unresolved, and what documents underpin everything. That accumulated context is what makes AI features in Agency Hero actually useful — the AI isn’t making things up; it’s reasoning from real knowledge that you and your team have produced.

This article explains how that knowledge is organized: the four distinct types that accumulate in any workspace, how each type works, and how they all connect to power search, AI chat, and automated workflows.

The four types of workspace knowledge#Copy link

Agency Hero separates workspace knowledge into four concepts. Each has a distinct role and lifecycle:

These four types are intentionally kept separate. Without the separation, a workspace quickly becomes a junk drawer — every attachment mixed in with every decision, meeting summaries tangled with strategic memos, topics reduced to simple tags. With the separation, each type serves a clear purpose and the system can reason about them cleanly.

Topics#Copy link

Topics are the longitudinal lens of a workspace. A topic represents a recurring theme or discussion thread — something that spans multiple meetings, chats, and interactions over time rather than belonging to a single session.

What topics do#Copy link

When the same subject comes up across meetings — say, “API Migration” appears in your kickoff, your week-3 check-in, and your Q2 planning call — the system maps each of those meeting-scoped discussions to the same canonical workspace topic. That topic then becomes the organizing entity for everything related to that theme:

• Decisions made across those meetings
• Risks and open questions that are still unresolved
• Tasks that trace back to the topic
• Memos and artifacts that address it

Topic briefs#Copy link

Each topic has a topic brief — a living summary synthesized from everything linked to that topic. Topic briefs are always derived, not manually authored. The system generates them from confirmed intelligence items, open tasks, and linked artifacts, and regenerates them whenever the underlying content changes.

A topic brief for “DevOps Migration” might show:

• The four decisions made across three meetings
• Two open risks still flagged as unresolved
• An outstanding question about vendor selection
• Three tasks in progress with owners and due dates
• A linked strategy memo from week 5

Because briefs are always derived from confirmed, linked content, you can refresh a brief at any time and trust that it reflects the current state. You cannot manually edit a topic brief — if you want a narrative document, use Artifacts instead.

How topics are created#Copy link

Topics are created automatically during meeting processing: when the post-meeting workflow detects a recurring theme, it maps it to an existing canonical topic or creates a new one. You can also create topics manually and link items to them yourself.

The canonical topic registry for a workspace lives in workspace_topics. Discussion statistics (how many meetings a topic has appeared in, first and last discussed date) accumulate over time, giving you a sense of what’s been most active.

Intelligence#Copy link

Intelligence is the atomic ledger of your workspace. Each intelligence item represents a single, confirmed piece of knowledge: a decision that was made, a risk that was identified, a question that is still open, a commitment that was given.

Intelligence types#Copy link

Agency Hero extracts 21 types of intelligence items, grouped by workspace context:

Core types (all workspaces)

• decision — a confirmed choice or resolution
• risk — an identified concern or potential problem
• question — an open item that still needs an answer
• proof — evidence of value delivered
• expansion — a growth or upsell opportunity

Deal workspaces

• commitment — a buyer or seller commitment
• objection — a challenge raised by a stakeholder
• assumption — an unverified belief the work is based on
• dependency — an external prerequisite
• constraint — a boundary on scope or approach
• competitor — a competitive signal
• proof_point — a customer success signal
• gap — a missing capability or information gap

Project workspaces

• scope_change — a confirmed change to project scope
• blocker — something actively preventing progress
• milestone — a significant progress marker

Ops workspaces

• incident — an operational event
• root_cause — the identified cause of an incident or issue
• metric_anomaly — a data signal outside expected ranges
• policy_exception — a deviation from standard operating procedure

Code / engineering

• code_change — a significant change captured from a code commit or PR

The proposal → confirmation lifecycle#Copy link

Intelligence items are never added to the workspace ledger without a human in the loop. The lifecycle is:

1. Proposed — the system extracts a candidate item from a meeting or chat interaction
2. Reviewed — the item surfaces in the post-meeting review UI or ABox attention queue
3. Confirmed — you accept it and it joins the canonical ledger
4. Dismissed — or you reject it and it’s discarded

Once confirmed, items can move to Resolved (an outcome was reached) or Reversed (a decision was changed). This lifecycle ensures the intelligence ledger stays clean — it contains things your team has affirmed, not raw unreviewed extractions.

What intelligence is not#Copy link

• Not for meeting summaries. Summaries are composed views derived from underlying items; they live on the meeting detail page and are not stored as intelligence.
• Not for long-form narratives. If you need a written analysis or strategy note, that’s an Artifact.
• Not a catch-all. Intelligence items have strict types. Vague ideas or notes don’t belong here unless they fit a type — use a memo instead.

Intelligence and topics#Copy link

Every intelligence item can be linked to one or more topics (with a primary topic flag). These links are what makes topic briefs work: when a risk is confirmed and linked to the “Pricing Alignment” topic, the brief for that topic automatically incorporates that risk.

Artifacts#Copy link

Artifacts are the narrative layer of your workspace — human-authored documents that capture strategy, analysis, decisions, plans, and conclusions. Where intelligence items are atomic (one decision, one risk), artifacts are longer-form and richer.

Memos: the first artifact kind#Copy link

The primary artifact kind today is the Memo. A memo is a flexible document — it can be a strategy note, a client recap, a scope discussion, a competitive analysis, a capture of what was concluded in a chat thread. The intent field classifies what a memo is for:

How artifacts are created#Copy link

You can create a memo from scratch, or you can create one from other sources:

• From a chat thread — use the Capture action on a conversation to turn a discussion into a structured memo
• From a topic brief — seed a memo from the current brief snapshot and then edit it to add narrative context
• From meeting items — select intelligence items or action items from a meeting and capture them into a memo

When you create a memo from existing items, the original items are not replaced or deleted. A confirmed decision stays in the intelligence ledger; the memo is a separate document that references it.

Artifacts vs. topic briefs#Copy link

Topic briefs are computed automatically. Artifacts are human-owned. This is an important distinction:

• A topic brief refreshes itself when linked items change. You cannot edit it.
• A memo is yours. Once created, it doesn’t auto-update. You’re in control of its content.

You can create a memo seeded from a topic brief if you want to crystallize the current state of a topic into a permanent document.

Context behavior#Copy link

Each artifact has a mode that controls how the AI uses it:

• retrieval_only — the memo is available for AI search (RAG) but not injected into every agent context. This is the default.
• always_read — the memo is always included in the agent context pack. Use this sparingly for small, high-value documents that the AI should always know about.

Future artifact kinds#Copy link

The artifact system is built to support additional kinds beyond memos: SOPs, playbooks, technical specs, strategy documents, and proposals are all planned. All artifact kinds share the same storage model and lifecycle.

Sources#Copy link

Sources are the raw inputs the workspace can read — documents, files, and data streams that provide retrieval substrate for AI. Where artifacts are things you author, sources are things you bring in.

What sources include#Copy link

Deal workspace seeding#Copy link

When you create a deal workspace, the system seeds it with placeholder sources for the document types most relevant to deal work: Statement of Work, Proposal, Commercials, and Objectives. These act as structural slots — you fill them with real content as the engagement develops. Work and ops workspaces are seeded differently, appropriate to their context.

Source modes#Copy link

Each source has a mode that controls how the AI uses it:

• retrieval_only — the source is available when the AI searches for relevant context (RAG retrieval), but it’s not automatically injected into every prompt. This is the right default for most sources.
• always_read — the source is always included in the agent context pack on every interaction. Keep this setting rare and intentional — context packs have token budgets, and over-injecting sources degrades AI quality.

Sensitivity controls#Copy link

Sources also have a sensitivity level separate from their availability to agents:

• normal — standard workspace access
• restricted — limited to specific grants
• excluded — never used by agents, regardless of mode

What sources are not#Copy link

• Meeting summaries are not sources. They are composed views derived from underlying intelligence and tasks. They live on the meeting detail page.
• Chat threads are not sources. Chat has its own search path. Threads don’t appear in the Sources tab and aren’t part of the workspace knowledge RAG substrate unless you explicitly capture content from them into a memo.
• Task comments are not sources. They are high-churn and excluded from context. If a comment contains durable insight, capture it as a memo.

Vectorization#Copy link

When you upload a document, it’s automatically chunked and embedded into the workspace’s vector store via a background Temporal workflow. The system uses 1,000-character chunks with 100-character overlap and generates embeddings using OpenAI’s text-embedding-3-small model. Once processing completes, the source is available for AI retrieval. You can track processing status on each source card in the Sources tab.

How the four types work together#Copy link

The four knowledge types aren’t independent silos — they’re designed to connect and reinforce each other.

Feeding the context pack#Copy link

When you chat with the AI or trigger a workflow, Agency Hero assembles a context pack — a curated projection of workspace knowledge that gives the AI accurate, current, evidence-backed context. The context pack is built from all four layers:

• From Topics: a snapshot of canonical workspace topics and their current state
• From Intelligence: open decisions, risks, and questions (DRQs) to ensure the AI knows what’s unresolved
• From Artifacts: always_read memos are injected directly; retrieval_only memos are available via search
• From Sources: always_read sources are injected; retrieval_only sources are available via RAG

The system is careful about what it puts in the context pack. Transcripts, full chat histories, and all uploaded documents are deliberately kept as retrieval substrate — not bulk-injected — to preserve context quality and token budget. The pack is about state, not corpus.

Topics as the connecting tissue#Copy link

Topics are the entity that links everything else longitudinally. When an intelligence item is confirmed and tagged to a topic, it feeds that topic’s brief. When a memo is linked to a topic, it appears in the topic’s knowledge picture. When sources are linked to a topic (a future capability), they become part of that topic’s retrieval set.

This means that over time, a topic like “API Architecture” in a product workspace accumulates: the architectural decisions made in three sprint reviews, the open blockers from two planning sessions, the spec memo your tech lead wrote, and the repo documentation that describes the actual implementation.

The enrichment loop#Copy link

Intelligence items don’t just serve the workspace — they also feed organizational learning. As patterns emerge across workspaces (the same objection appearing across five deals, a proof point that correlates with closed-won outcomes), the enrichment engine can propose refinements to org-level knowledge: updating buyer personas, adding to the proof library, refining deal stage runbooks.

These proposals always require human review and confirmation before they update org knowledge. Workspaces inform the organization; they don’t auto-update it.

The Workspace Guardian#Copy link

The Workspace Guardian is a long-running background workflow (one per workspace) that keeps the workspace’s ABox attention queue coherent. It watches for signals — meetings processed, tasks created or updated, knowledge events — and ensures the right items surface for your attention at the right time. For example, if a meeting’s review window is approaching without action, Guardian escalates it. If a task becomes overdue, Guardian updates its placement in your attention queue.

Guardian is deterministic — it doesn’t make AI calls or decide what content persists. Its job is to keep the attention routing correct so that knowledge events don’t fall through the cracks.

The Knowledge tab#Copy link

You access a workspace’s knowledge from the Knowledge tab, which is organized into four sub-sections corresponding to the four knowledge types:

• Topics — the canonical topic list with briefs and linked items
• Intelligence — the confirmed intelligence ledger, filterable by type and status
• Artifacts — memos and other narrative documents
• Sources — uploaded documents, seeded files, and included org knowledge

Each section shows only what belongs to that category. Meeting summaries, raw transcripts, and chat history are not listed here — they live in their own dedicated areas (the meeting detail page and chat threads respectively).

Key things to remember#Copy link

• Intelligence items require confirmation. Nothing enters the intelligence ledger automatically — every item passes through human review first.
• Topic briefs are derived, not authored. They’re always fresh, always regenerable, and never directly editable.
• Memos are yours. They don’t auto-update. They’re the place for human-authored narrative that you control.
• Most sources should stay retrieval_only. Only mark a source always_read if it’s small, high-value, and genuinely needs to be in every AI interaction.
• Meeting summaries are not knowledge artifacts. They’re views. Durable conclusions belong in confirmed intelligence items, topic briefs, or memos.
• Chat threads are not sources. Use the Capture action to turn a valuable chat discussion into a memo if you want it in the knowledge ledger.