Managed work delivery architecture
Select a layer to inspect its responsibility and operating boundary.
Customer & SMEs
Assign outcomes, supply approved source material, verify domain facts, and make reserved business decisions.
THINK Strategist
Scopes assignments, directs the Managed Team, coordinates exceptions, and reviews quality.
Team Orchestrator
Owns team-specific workflow, job sequencing, and Digital Employee handoffs.
Digital Employees
Perform specialized assigned jobs using reusable skills and permitted capabilities.
THINK Harness
Supports shared context, routing, policy, state, evaluations, and capability resolution; it does not replace team ownership.
Approved Tools & Systems
Provide execution and information access only within the approved customer, identity, and workflow boundaries.
Review & Delivery
Validated work is reviewed by the strategist and customer approvers when required before final delivery.
Conceptual architecture based on documented responsibilities; this diagram does not assert that every component is deployed in production.
Managed Work Delivery Architecture
Compound Leverage delivers assigned work, not infrastructure as a standalone product. Assignments may produce research, reports, proposals, presentations, software code, integrations, automation, configured solutions, or other agreed deliverables.
Customer assignment → THINK Strategist → Managed Team → Authorized execution → Validation and human quality review → Customer approval (when required) → Finished work
Two execution arrangements
| Compound Leverage-managed delivery | Customer-environment delivery | |
|---|---|---|
| Work | Customer assigns an outcome or deliverable | Customer assigns an outcome or deliverable |
| Execution location | Compound Leverage-managed tools and approved infrastructure | Customer-approved repositories, tools, infrastructure, or other systems |
| Workforce management | THINK Strategist directs and reviews work | THINK Strategist directs and reviews work under agreed access arrangements |
| Customer systems | Access only where authorized | Customer controls applicable credentials, access, and environment policies |
| Output | Agreed finished artifact or solution | Agreed finished artifact or solution in the approved destination |
| Production changes | Require separate authorization | Require customer authorization and applicable change controls |
These are delivery arrangements, not two different products. Customer-environment delivery depends on the specific engagement and approved technical access; it is not a claim that every runtime is available in every customer environment.
Architecture components and evidence
| Component | Purpose in work delivery | Source of truth |
|---|---|---|
| Managed Teams and Digital Employees | Specialized jobs and reusable work methods | THINK-internal: THINK-Internal/ and THINK-Commercial/Teams/ |
| THINK Harness | Shared intelligence, context, routing, policy, state/memory, evaluations, and capability resolution | THINK-internal: THINK-Internal/Harness/README.md |
| Commercial Harness | Customer deployment configuration, governance eligibility, entitlements, and release gates | THINK-internal: THINK-Commercial/Harness/README.md |
| MCP capability boundary | Exposes approved capabilities while separating internal and customer-controlled access | THINK-internal: THINK-Commercial/MCP/README.md and platform-spec/mcp-boundary.md in CL-website |
| Orchestration and execution | Coordinates work, task transitions, exceptions, and execution tools | THINK-internal: THINK-Internal/Execution/team-orchestrator/ |
| Human approval and quality | Reviews results and authorizes consequential actions | Work Orchestration and Governance |
These source paths identify documented design or code. They do not, on their own, establish that a service or control is deployed in production.
Work types and review
| Assigned work | Example output | Typical validation |
|---|---|---|
| Capture and proposal | Opportunity assessment, response draft, review findings | Source checks, completeness, strategist review |
| Research and analysis | Brief, report, model, presentation | Evidence and consistency review |
| Software development | Code change, application, integration, automation | Tests, code review, security checks as applicable |
| System configuration | Approved workflow or system change | Configuration validation and authorized acceptance |
Writing code, delivering code, and deploying code are different permissions. No assignment implicitly authorizes production deployment.
Technical documentation
Work Execution Layer · MCP and Integrations · Service Activation and Delivery Arrangements · Security and Governance · Customer Access and Data Controls
For underlying concepts, see Model Context Protocol, Google Cloud Architecture Framework, and GitHub Actions documentation. These external references explain technologies; they are not claims about Compound Leverage’s deployed configuration.