Use case · Positioning
Build the workflow. Reuse the operating foundation.
Last updated:
In short
Outloop is Workspace infrastructure for deploying and operating AI workers.
Outloop gives Forward-Deployed Engineers and AI implementers a durable Workspace for client identity, Context, approved accounts and resources, working methods and supported execution. Reuse reviewed implementation work, then configure and validate each client separately. Outloop runs on a company-controlled Mac today.
| Layer | Reusable method | Client-specific setup |
|---|---|---|
| Workflow | Reviewed steps, Skills and Routine patterns | Client brief, approvals and validation |
| Systems | Supported integration pattern | Approved account and resource identifiers |
| Runtime | Supported engine configuration approach | Readiness and workload verification |
| Private state | No automatic transfer | Context, files and work history stay with the client |
You implement the business workflow.
Define the outcome, connect the business steps, decide what needs human review and verify the result. Outloop provides the Workspace around that implementation: the intended client, approved Context and access, working methods and records.
It is an operating foundation for supported AI work, not a general agent framework or an FDE project-management system. Your model, runtime and customer systems remain separate choices. See current Product scope.
Reuse the method. Configure each client.
The first implementation establishes the workflow, integrations and reviewed methods. Later Workspaces reuse that work rather than starting from zero. For supported multi-client services, such as approved advertising-platform setups, the integration can already exist while each Workspace is configured with the correct client account and resource identifiers.
Client A’s Context
Approved accounts & resources
Access, files & work records
Client B’s Context
Approved accounts & resources
Access, files & work records
Client C’s Context
Approved accounts & resources
Access, files & work records
- First implementation: establish supported systems, build the workflow logic and Skills/Routines, and validate the task and its boundaries.
- Next Workspace: reuse the reviewed client-neutral implementation; configure its own Context, approved accounts, resources, access and browser mode.
- Before repeated use: verify the intended client target, an approved task, the relevant refusal boundary and the reviewable output.
This leverage is demonstrated qualitatively in implementation work. The setup hours, custom work and repeatability across external implementers still need measurement. It is not one-click cloning.
Keep the client boundary through real execution.
A job may use an API, browser, authentication handoff, files or installed applications. Supported actions remain associated with the intended Workspace and approved resources. A refused action is not permission to bypass the boundary through another tool.
Local Chrome mode uses the Workspace’s configured profile for supported work and Browser Login. Managed Browser uses a shared profile and supports verified recovery on the same task page. Some authentication still requires a person. Explore execution and login handoffs and inspect recorded client-boundary proof.
See the workflow your implementation should support.
Follow one agency job from client Context and approved assets to human review and a verified campaign build. Use it as a concrete example when scoping a client implementation.
An implementation outcome example, not a complete deployment or client-onboarding tutorial.
- Approved client Context and brand assets
- Human review before execution
- Real campaign objects, kept PAUSED
Create your trial, then install on your company-controlled Mac. Set up your first workspace.
67-second Ellātu preview · Google Ads + Meta · No form required
Demo brief and assumptions. Real Google Ads and Meta execution, configured PAUSED. Review emails are labeled staged reconstructions. No delivery or performance claim.
Let the runtime change without redefining the client.
Use the model that makes sense for the work. Keep the Workspace around it. A lower-cost supported option matters when it meets the workload’s requirements; frontier models remain useful where capability justifies cost.
Stable 1.45.0 Routines retain instructions, schedule and history between ready Claude Code and Codex runtimes. Open/local options require specific support and workload verification. Outloop does not automate cost-based selection or migrate every session. Compare total cost per workload.
Scope the first deployment around a deliverable.
Bring one client task, its source and destination systems, the approved accounts/resources and a definition of a correct result. Start with a bounded workflow and expand after validation.
Multi-client agency operation · A repeatable GTM workflow · First-Workspace setup.
The intended client, approved action and reviewable result
- 01
Client task
Start with the intended client and a defined result.
- 02
Approved Workspace
Use this client’s Context, accounts and resources.
- 03
Supported action
Work through the approved API, browser or file path.
- 04
Reviewable result
Inspect the output and involve a person where required.
- 05
Work history
Keep the work record with the intended Workspace.
Conceptual workflow. Supported actions depend on the configured service, runtime and approved resources.