The Curriculum / Reader / Cross-Team Workflows
LEVEL 2 · INTERMEDIATE · COMPANY TRACK

Cross-Team Workflows

This page compiles 4 files from the repository, verbatim, in reading order. The living version: this folder on GitHub.

level-2-intermediate/company/08-cross-team-workflows/README.md

Cross-Team Workflows

Shared agents and knowledge multiply value only when ownership, access, and escalation are explicit. A support agent, a research agent, a diligence tool, and an executive dashboard should exchange typed facts and accountable handoffs — not improvised chat transcripts.

Build shared services around common contracts: identity, entity IDs, source citations, status taxonomy, audit trace, and human owner. Publish knowledge deliberately with audience and freshness rules. Escalations must land with a team that has context and authority.

The documents cover reusable agents, shared knowledge, and cross-team escalation. Reuse is earned through stable boundaries, not by making one giant company bot.

Related: individual foundations

Cross-team workflows only work if each person on each team has their own knowledge vault in order — otherwise every handoff involves re-explaining context. If your team members struggle with "AI doesn't know my preferences" or "I keep re-explaining myself," they need the individual foundation from Groundwork Layer 2 (Knowledge), not more org tooling. See GROUNDWORK-AND-FLUENCY.md.

Operating standard

Make this practice operational, not aspirational. Assign one directly responsible owner and name the decision they can make without another meeting. Put the key measure, threshold, and review cadence in the owning team's regular operating rhythm. A change to model, prompt, data scope, retrieval index, tool permission, or policy should be recorded with its expected impact and a rollback path. Preserve enough trace information to explain an individual bad outcome without exposing more customer or internal data than necessary. Review a small sample of real runs with the people doing the work; dashboards reveal trends, but operators reveal missing context. When the rule is violated, capture the incident, contain impact, add an eval or control, and update this document if the standard itself was unclear. The point is repeatable judgment under real workload, not a one-time compliance exercise.

level-2-intermediate/company/08-cross-team-workflows/escalation-across-teams.md

Escalation Across Teams

An agent escalation must create an accountable handoff, not an orphaned notification. Define trigger, severity, destination role, required context, SLA, and acknowledgement behavior for each category: maintenance emergency, lease/legal question, payment dispute, fair-housing concern, diligence blocker, security incident, and platform failure.

Pass a compact packet: source message or document link, classification, confidence, citations, prior actions, requested decision, tenant/property/deal IDs, and trace ID. Do not rely on the receiving team to reconstruct context from a chat log. The agent must stop acting after escalation unless policy explicitly allows a safe acknowledgement.

Measure time to acknowledgement, time to resolution, routing correctness, reassignment rate, and repeated escalations. Review missed or bounced handoffs as incidents. Cross-team automation succeeds when it reduces coordination loss without blurring who owns the decision.

Operating standard

Make this practice operational, not aspirational. Assign one directly responsible owner and name the decision they can make without another meeting. Put the key measure, threshold, and review cadence in the owning team’s regular operating rhythm. A change to model, prompt, data scope, retrieval index, tool permission, or policy should be recorded with its expected impact and a rollback path. Preserve enough trace information to explain an individual bad outcome without exposing more tenant or deal data than necessary. Review a small sample of real runs with the people doing the work; dashboards reveal trends, but operators reveal missing context. When the rule is violated, capture the incident, contain impact, add an eval or control, and update this document if the standard itself was unclear. The point is repeatable judgment under real workload, not a one-time compliance exercise.

level-2-intermediate/company/08-cross-team-workflows/shared-agents.md

Shared Agents

A shared agent should provide a narrow capability with a stable contract: lease clause retrieval, document classification, policy-safe drafting, or contact normalization. It exposes typed inputs/outputs, scopes access by caller, publishes an eval baseline, and has an owner. It does not become a universal assistant with hidden privileges.

Version the contract and support consumers through a gateway or MCP layer. Require teams to pass their organization context and receive only authorized results. Track each consuming workflow’s cost, errors, and model policy separately. Changes that alter semantics need compatibility review.

Create a catalog with purpose, owner, risk tier, data scope, examples, SLOs, and integration path. Shared agents save work only when callers can trust their boundaries.

Operating standard

Make this practice operational, not aspirational. Assign one directly responsible owner and name the decision they can make without another meeting. Put the key measure, threshold, and review cadence in the owning team’s regular operating rhythm. A change to model, prompt, data scope, retrieval index, tool permission, or policy should be recorded with its expected impact and a rollback path. Preserve enough trace information to explain an individual bad outcome without exposing more tenant or deal data than necessary. Review a small sample of real runs with the people doing the work; dashboards reveal trends, but operators reveal missing context. When the rule is violated, capture the incident, contain impact, add an eval or control, and update this document if the standard itself was unclear. The point is repeatable judgment under real workload, not a one-time compliance exercise.

level-2-intermediate/company/08-cross-team-workflows/shared-knowledge.md

Shared Knowledge

Publish knowledge as governed sources, not a bucket of PDFs. Every item has owner, audience, classification, effective date, expiry/review date, source of truth, version, and retrieval scope. A policy page without an owner should not become authoritative because an embedding makes it easy to find.

Separate tenant-specific, team-private, company-internal, and public content. Retrieval filters enforce these labels. Add citation and freshness display so a user can inspect authority. Establish a correction path and reindex SLA for changed material.

Shared knowledge is useful when people know what it means, who maintains it, and when not to rely on it.

Operating standard

Make this practice operational, not aspirational. Assign one directly responsible owner and name the decision they can make without another meeting. Put the key measure, threshold, and review cadence in the owning team’s regular operating rhythm. A change to model, prompt, data scope, retrieval index, tool permission, or policy should be recorded with its expected impact and a rollback path. Preserve enough trace information to explain an individual bad outcome without exposing more tenant or deal data than necessary. Review a small sample of real runs with the people doing the work; dashboards reveal trends, but operators reveal missing context. When the rule is violated, capture the incident, contain impact, add an eval or control, and update this document if the standard itself was unclear. The point is repeatable judgment under real workload, not a one-time compliance exercise.

← Adoption Metrics Level 2 shared materials →