Context and capability resolution
Follow an approved capability request, including the fail-closed path.
Assigned Job
A Digital Employee requests a named capability needed for an authorized task.
Context & Identity
The Harness considers approved customer sources, assignment scope, and identity context.
Policy Check
Permitted capability is constrained by human authorization, Digital Employee authorization, and workflow policy. Unapproved requests stop.
Provider Binding
An eligible capability identifier resolves to an approved provider, if one is configured.
Tool / MCP Operation
An approved provider performs the scoped operation or rejects it. Read does not imply write or deployment authority.
Validate / Escalate
Results return to the team for evaluation and human review; blocked work is escalated.
Denied or unavailable: Stop the operation and escalate. Do not bypass identity, policy, or tenant boundaries.
Conceptual architecture based on documented responsibilities; this diagram does not assert that every component is deployed in production.
Context and Capability Resolution
Context and capability resolution determines which authorized information, methods, and tools an internal workforce role may use for a particular assignment.
Resolution flow
Customer request → THINK Strategist assignment → Required skill → Authorized context → Approved tools → Work output → Quality review
The goal is to provide the resources needed for the work without exposing unrelated customer information or unnecessary capabilities.
Boundaries
A role’s technical ability to call a tool is not authorization to use it. Access must be consistent with the assigned work, approved customer-system permissions, and applicable policy. Missing context or permissions should be escalated to the THINK Strategist.
Customer experience
The customer does not configure these internal mechanisms. They assign work, provide direction and judgment, review artifacts, request revisions, and approve finished deliverables where applicable.
See Workforce Skills and Security and Governance Model.
Detailed resolution sequence
| Step | Component | Input | Result |
|---|---|---|---|
| 1 | THINK Strategist and team orchestrator | Assignment, customer instructions, acceptance criteria | Scoped task and assigned role |
| 2 | Digital Employee or skill | Named capability need and required context | Capability request |
| 3 | Harness context and policy support | Authorized sources, assignment context, governing policy | Eligible context and permitted operations |
| 4 | Capability resolution | Stable capability identifier and available providers | Approved provider binding |
| 5 | MCP, runtime-native tool, or API | Authorized request | Operation result or rejection |
| 6 | Team workflow and human reviewer | Result, evidence, and exceptions | Validated output or escalation |
The source specification uses the expression Human authorization ∩ Digital Employee authorization ∩ workflow policy = permitted capability. A role’s technical ability to call a provider is not sufficient permission.
Documented capability mappings
| Capability ID | Example implementation | Meaning |
|---|---|---|
notion_read | MCP / Notion | Request approved Notion read capability |
github_read | MCP / GitHub | Request approved repository read capability |
market_intelligence | THINK Intelligence plus approved research tools | Request research intelligence |
These mappings are examples from THINK-Internal/Harness/capability-resolution/README.md, not a list of universally deployed connectors. Provider details can change without rewriting the Digital Employee’s stable job definition.
Context ownership
| Context type | Source and owner | Rule |
|---|---|---|
| Reusable job instructions | Internal workforce definitions | Do not embed customer proprietary data |
| Shared methods and intelligence | THINK Harness | Apply applicable policies and evaluations |
| Customer-specific sources | Customer-approved systems and materials | Keep within agreed access and data boundaries |
| Task-specific inputs | Customer assignment and strategist scope | Use for the authorized work only |
| Execution state | Team workflow and configured state support | Respect assignment and customer boundaries |
Example: code assignment
A Digital Employee assigned to analyze a repository may request github_read. The resolution layer must select an approved provider under the relevant customer and workflow permissions. Read access does not imply write, merge, or deploy access. If access is missing or the requested operation exceeds scope, the work is blocked and escalated rather than silently switching identities.
Troubleshooting
| Condition | Investigation | Response |
|---|---|---|
| No context returned | Confirm source authorization and task scope | Ask the strategist for approved inputs |
| Provider unavailable | Check configured capability binding | Select an approved alternative or revise the plan |
| Identity/tenant mismatch | Check customer, deployment, and user identity | Reject; correct the identity configuration |
| Tool action exceeds scope | Compare requested action to approved permissions | Obtain authorization or stop |
| Output lacks evidence | Inspect sources and evaluation criteria | Revise or disclose limitations |
Source references and related pages
Internal source: THINK-Internal/Harness/context/README.md, THINK-Internal/Harness/capability-resolution/README.md, and platform-spec/mcp-boundary.md.
Work Execution Layer · MCP and Integrations · Customer Access and Data Controls · Security and Governance