Work Execution Layer
The execution layer supports work delivery, including research, document production, analysis, software development, integrations, configuration, and automation. Execution may use models, agents, code, conventional applications, or approved external tools.
Components
| Component | Role | Implementation reference |
|---|---|---|
| THINK Harness | Shared context, intelligence, routing, policy, state/memory, evaluations, capability resolution | THINK-internal: THINK-Internal/Harness/ |
| Commercial Harness | Customer-specific configuration, entitlements, governance eligibility, release gates | THINK-internal: THINK-Commercial/Harness/ |
| Orchestration | Assignment coordination and workflow execution support | THINK-internal: THINK-Internal/Execution/team-orchestrator/ |
| MCP and adapters | Controlled tool/capability interfaces, customer adapters, and authorization | THINK-internal: THINK-Commercial/MCP/customer-adapters/ |
| Workflow and lifecycle hooks | Event-triggered automation and checks, where implemented | THINK-internal: .github/workflows/ and execution-specific source; verify each hook’s purpose before claiming runtime behavior |
The presence of source code, tests, or configuration does not prove a production deployment. The internal deployment architecture also identifies commercial capabilities whose deployment infrastructure was not yet implemented when that document was written.
Harness: shared services versus team ownership
The THINK Harness is a shared support layer, not a replacement for the Managed Team’s own workflow. The internal Harness README identifies seven capability areas:
| Harness area | Documented purpose | What it means for assigned work |
|---|---|---|
| THINK Intelligence | Shared intelligence services | Reusable intelligence can support research and analysis tasks |
| Capability resolution | Maps named capability requests to approved implementations | Digital Employee job definitions do not need provider-specific tool names |
| Context | Assembles context across teams and approved sources | Customer-specific context remains governed separately from reusable jobs |
| Orchestration support | Routing, handoffs, blocked work, escalation, human gates | Team orchestrators retain ownership of their workflow |
| State and memory | Shared state/memory support | Work can reference the appropriate governed state as configured |
| Evaluations | Shared quality criteria and runtime/release validation | Common checks can be reused; team-specific checks remain with the team |
| Policy | Shared policy support | Capability use is subject to the appropriate authorization boundary |
These are documented architecture responsibilities. Whether a particular feature is active for an engagement depends on its implementation and deployment.
Capability mapping example
The internal capability-resolution documentation gives these illustrative mappings:
| Requested capability | Documented example resolution |
|---|---|
notion_read | MCP / Notion |
github_read | MCP / GitHub |
market_intelligence | THINK Intelligence plus approved research tools |
A team asks for a capability, while configuration selects an authorized provider. The examples describe the mapping model, not a promise of connector availability.
Shared context versus customer context
Reusable Digital Employee definitions should not contain customer proprietary information. Instead, the Harness supports assembling context from approved sources under the appropriate customer controls. See Customer Access and Data Controls.
Execution examples
Capture research
- A customer assigns an opportunity assessment and supplies approved context.
- The strategist identifies the relevant Managed Team and acceptance criteria.
- Team roles request approved research capabilities and produce a draft assessment.
- Relevant evaluation criteria and human review check evidence and completeness.
- The customer receives the reviewed assessment; consequential decisions remain with the authorized human.
Code and integration work
- A customer specifies the requested integration, repository, acceptance criteria, and access.
- The strategist scopes whether work includes code authoring, tests, repository changes, or deployment.
- Authorized capabilities support implementation and testing in the agreed environment.
- Human reviewers examine results and failed checks or exceptions.
- Code is delivered or applied within approved scope; production deployment is a separate authorization.
Verification and limitations
| Evidence in THINK Internal | Supported conclusion | Not established by that evidence |
|---|---|---|
| Harness README and submodule documentation | Shared-service architecture and intended boundaries | Every capability is running in production |
| Commercial Harness schemas and tests | Defined configuration and tested validation paths | A fully provisioned customer environment |
| Team orchestrator source and deployment workflow | Orchestration implementation and deployment mechanism exist | Current runtime health or complete workflow coverage |
| Git hooks and CI workflows | Development/release automation exists | AI execution hooks or approval gates are active at runtime |
Internal source references: THINK-Internal/Harness/README.md, THINK-Internal/Harness/capability-resolution/README.md, THINK-Internal/Harness/context/README.md, THINK-Internal/Harness/orchestration-support/README.md, and THINK-Internal/Harness/evaluations/README.md.
Related technical references
Work Orchestration · MCP and Capability Integrations · Security and Governance · Google Cloud Architecture Framework
Executing assigned work
| Phase | Non-code work | Code-based work |
|---|---|---|
| Scope | Define evidence, format, and decision criteria | Define requirements, repository, environment, and acceptance tests |
| Execute | Research, analyze, draft, assemble | Develop, configure, integrate, automate |
| Validate | Check evidence, completeness, consistency | Run relevant tests and review code/configuration |
| Review | THINK Strategist reviews and escalates | THINK Strategist and authorized technical reviewers evaluate changes |
| Deliver | Approved artifact or report | Code, solution, documentation, or authorized deployment |
Environment and authorization boundaries
Work can be completed through CL-managed delivery or an approved customer environment. Access is limited to authorized resources and work. Customer credentials and enterprise permissions remain subject to customer-approved controls. Production changes require explicit approval separate from permission to write or deliver code.
Related documentation
Managed Work Delivery Architecture · Service Activation · MCP and Integrations · Tools and Enterprise Integrations · Security and Governance