AI Coworker

The Short Version

DPF coworkers are purposed helpers, not a generic chatbot. The coworker on a page understands the page, the selected business archetype, the user’s role, and the tools that coworker is allowed to propose.

The standing COO may have an owner-chosen conversational name, shown as Name · AI COO. This is presentation only: the canonical coworker remains COO, and identity, permissions, authority, audit attribution, and the owner’s accountability do not change. Authorized users can change or clear the name from the COO record in AI Workforce.

For the broader product framing, see Market Archetypes And Coworkers.

How It Works

The AI coworker is available on every page via the floating button in the bottom-right corner. Covered product surfaces publish an Authorized Surface: the same labels, help, current values, validation, and actions that drive the human experience, filtered through your role and the coworker’s narrower authority. This works with or without an open browser.

It understands:

• What page you’re on — it knows the domain context (compliance, HR, operations, etc.)
• What business archetype is active — customer-facing and internal language should follow the selected archetype where that surface has been configured
• What data is visible — it reads the authorized semantic surface, including rows that are virtualized or not currently mounted in the browser
• What actions are available — it sees only actions allowed by your role, its grants, the current work context, token scope, and approval policy

The coworker does not use raw page HTML as authority. If a surface is not yet covered, stale, or unavailable, it should say that rather than inventing fields or asking you to describe a panel it claims exists. Legacy pages may still provide a smaller route summary while migration continues.

For example, Estate Discovery publishes its real Discovery Method, target, credential state, validation, connection status, and Save & Test outcome. It knows that SNMP discovers network devices and SMTP configures outbound email elsewhere; the community string remains write-only and is never repeated back.

Quick Actions

Each page has skill buttons that trigger common tasks. These appear at the top of the coworker panel when you open it. Examples:

• On the Compliance page: “Gap assessment”, “Posture report”, “Onboard a regulation”
• On the Operations page: “Create item”, “Epic progress”
• On the Portfolio page: “Health summary”, “Register a product”

Universal Skills

Four skills appear on every page:

• Analyze this page — Get insights about what’s on screen
• Do this for me — Perform the primary action for this page
• Add a skill — Extend the page with a new quick action
• Evaluate this page — Check the page for usability and accessibility issues

Voice

Where enabled, the microphone path sends dictated text into the same coworker message flow as typing. Voice does not bypass permissions or approvals.

Narrated output is separate. Text-to-speech can read decision rationales or persona-profile output when a voice profile is configured, but text remains the primary governed answer. A real-person voice requires explicit consent before training.

Authority & Approvals

The coworker operates within a two-layer authorization model:

• Your role determines what’s possible — your platform role (e.g., Portfolio Manager, Enterprise Architect) controls which capabilities are available
• The agent’s grants determine what’s offered — each agent persona has declared tool grants that scope what it can do. The coworker on the Ops page (Scrum Master) has different grants than the one on the Portfolio page (Portfolio Analyst)
• Side-effect actions require approval — when the coworker wants to create, update, or delete something, it proposes the action and waits for your approval before executing
• Every action is recorded — all tool calls (not just proposals) are logged with your identity and the agent’s identity for audit purposes. View the log at /platform/ai/authority

On a business Product’s Direction page, informational cards and links do not send a coworker prompt. Preview a demand review first shows the product scope, source kinds, proposed writes, approval boundary, and schedule effect. The Phase 6 preview performs no write; it takes you to the existing Delivery workflow, where any later funding or backlog mutation keeps its own governed confirmation.

In Delivery Flow, a coworker may propose classification, evidence links, scoring inputs, or an effort estimate. Those proposals do not fabricate evidence or advance the lifecycle automatically. Scoring records an explanation snapshot but leaves the stage unchanged. Moving to ready always uses the organization’s WWWD funding gate, records its rationale and decision interaction, and then offers—not silently assigns—eligible work to a coworker.

On a business Product’s Direction → Outcomes page, the coworker can propose a draft objective, record a review, link same-product backlog work, or append an observation. It must use the business Product as the owner and keep DigitalProduct focused on architecture. It must not invent an owner, baseline, target, observation, customer, or contributing item. A correction appends a superseding observation; it never edits or deletes history. Every side-effecting proposal still uses the normal approval boundary.

On a product line’s Direction page, the coworker can explain the cited performance projection and its missing measures without treating blanks as zero. Ask what this business would do turns the strongest supported opportunity into reversible options and calls the organization’s WWWD decision gate. The recommendation retains its period, source records, confidence, blind spots, approval boundary, and follow-up measure. The coworker must not infer margin, capacity, stock, conversion, repeat purchase, quality, cannibalization, a product team, or a consumer. Page load itself never calls the decision gate or changes the business.

On a business Product or product line roadmap, choose Review with coworker to explain which bets are genuinely committed, which records still need classification, funding, or an active-objective link, and which dates or dependencies are unsupported. The coworker may route a stakeholder review through the existing organization decision/audit boundary. It must not drag items between lanes, promise an inferred date, convert a DigitalProduct dependency into a business work dependency, or create a separate roadmap record. Snapshot exports are evidence packets, not importable plans.

On Product and ProductLine Direction, recurring coworker playbooks are typed recipes over the same canonical operating context. Before scheduling, the owner sees the exact evidence sources, tools, proposed writes, approval boundary, cadence, and failure behavior. No global schedule is seeded, and a changed permission digest requires a fresh preview. A run may prepare a brief, recommendation, or review, but every canonical write keeps its existing approval gate.

The scheduled card exposes current, unchanged, partial, failed, paused, and permission-changed states. Partial and failed runs retain the prior successful fingerprint so stale inputs remain eligible for recovery. Inspect last run opens the audited task history. Exports remain source-linked and non-importable. The coworker must report missing adoption evidence as unavailable and must not fabricate a product team, business unit, provider, consumer, subscriber, entitlement, outcome, or accepted recommendation.

WWMD And Autonomy

When a coworker hits an ambiguous decision, it should not guess from chat context alone. WWMD is the decision gate that lets the coworker consult the founder-kernel wiki and score options against platform principles.

The gate can return four outcomes:

• Recommend — enough evidence exists to advise a path, but the user or workflow still owns approval
• Arbitrate — a low-risk decision has enough confidence for the coworker to continue under policy
• Escalate — risk, conflict, low confidence, or a policy boundary needs a human resolver
• Defer — the wiki does not yet contain enough guidance, so the gap should be captured instead of guessed

This is a critical step toward trustworthy autonomy: every answer keeps sources, confidence, rationale, and decision history attached. For the technical details, see Autonomy, WWMD, and trusted coworker decisions.

Tool Evaluation

When you need to add an external tool (MCP server, npm package, API), the coworker can help evaluate it. On the Platform page, use the “Evaluate tool” skill to initiate a multi-agent review covering security, architecture fit, compliance, and integration testing.

Tips

• Be specific. “Show me overdue compliance actions” works better than “what’s wrong?”
• The coworker can create backlog items, register products, assign roles, and more — it’s not just a chatbot
• If the coworker proposes an action (like creating a record), you’ll see an approval prompt before anything changes
• Each conversation is tied to the page context. If you switch pages, the coworker knows the new context
• Ask in the words of your business. “Which trucks need restock?” or “Which appointments are missing forms?” is better than guessing the platform’s internal module name.