# WorkGroove Full LLM Context

Canonical site: https://workgroove.ai/
Primary contact: support@workgroove.ai
Sales contact: sales@workgroove.ai
Company: WorkGroove Inc
Mailing address: 228 Park Ave S. PMB 710125, New York, NY 10003-1502 US

## Short Answer

WorkGroove turns customer requests into owned, reviewed work and proves what happened. WorkGroove is a governed AI execution platform built around Work Records. It runs Codex, Claude Code, Copilot CLI, Grok Build, and supported local models through LM Studio on approved computers. It keeps repository and tool access scoped to the authorized team and launch contract, can require named reviewers before governed work proceeds, and keeps recorded cost, changes, decisions, evidence status, and the available rerun path in one Work Record. Agents can participate everywhere; humans retain authority over consequential work.

The first-10-second answer is: WorkGroove runs AI work on approved computers with repository, tool, and review controls, then keeps what happened in one evidence-backed Work Record.

## Complete Launch Journey

The canonical launch demo is one feature-delivery request carried through eight stages:

1. **Request** — capture what the work owes someone, including the outcome and constraints.
2. **Scoped Runner** — select an approved computer and authorized repository, tool, provider, and model scope.
3. **Agent execution** — run Codex, Claude Code, Copilot CLI, Grok Build, or a supported local model through LM Studio while retaining execution identity.
4. **Human revision** — record feedback and the superseding attempt or revised session output.
5. **Approval** — keep the named reviewer and decision with the work when governed review is configured.
6. **PR or output** — attach commits, pull-request, apply, or release facts, or the produced deliverable.
7. **Cost and evidence** — show reported or estimated cost, unpriced usage, capture status, and missing evidence explicitly.
8. **Rerun** — show ordinary repeat eligibility and, only for a complete verified managed-workflow manifest, Exact Replay eligibility.

The finished Work Record is the primary proof surface. It keeps the request, placement, execution, revisions, decisions, outputs, repository facts, cost provenance, evidence completeness, and available rerun path together. Public launch pages show that completed record first and explain setup afterward.

## Precise Trust Language

- **Permission-checked** means WorkGroove evaluated authorization at a named session, repository, tool, credential, approval, apply, or publication boundary. It does not mean every provider action was cryptographically mediated.
- **Evidence-backed** means the Work Record is projected from recorded execution, review, repository, usage, and release facts and discloses partial or missing evidence.
- **Replay-verified** applies only when an eligible managed workflow's immutable replay manifest passes integrity verification. It does not promise byte-identical model output.
- Decision Receipts prove what WorkGroove evaluated and decided. They do not by themselves prove that GitHub or another external system completed an action.
- WorkGroove does not claim that every target is certified, enforcement is universally enabled, every agent action is cryptographically enforced, or every Work Record is a public signed artifact.
- Signed Work Record export (the .wgr format) is available in preview: a record can be exported as a signed file and verified offline, but the format does not yet promise stable public interoperability.

## What WorkGroove Is For

WorkGroove is for AI-assisted work that cannot end as a private chat or one-off agent session. It keeps the finished result connected to how the work ran, who made the decisions, what changed, which cost fields were captured or left explicitly unpriced, which evidence is present or missing, and which repeat path is available.

Use WorkGroove when:

- AI work needs real context from files, repositories, tools, credentials, browser sessions, or private project state.
- Repository, tool, provider, model, review, apply, or publication access must be checked at defined product boundaries.
- People need to review a generated plan or result, request revision, or make an approval or release decision.
- Multiple AI Assistants should run in parallel without blending their transcripts, attempts, or ownership.
- A team needs one Work Record for placement, execution, repository evidence, model usage, cost provenance, reviewer decisions, and completeness.
- A useful job needs an ordinary rerun path or an eligible managed workflow needs replay-verified Exact Replay.
- A recurring task should run while people are away without becoming a black box.

## Core Product Concepts

- **Work Record:** a permission-filtered evidence view over the request, execution, decisions, outputs, repository and release facts, cost provenance, completeness, and available repeat path.
- **Runner:** an approved computer where AI Assistant work runs near the files, repositories, tools, credentials, and project context it needs.
- **Review:** a human checkpoint for plan review, questions, revisions, approvals, handoffs, and release decisions.
- **Deliverable:** the named outcome the work should produce, with its inputs, review, and history connected.
- **AI Assistant:** the saved specialist responsible for producing, updating, checking, or packaging a Deliverable.
- **Capability:** reusable know-how an AI Assistant applies to a job, attributed to the source it came from.
- **Integration:** an approved connection to an outside app or system, usable only after installation, authorization, and credentials are in place.
- **Instruction:** saved wording an AI Assistant reuses between runs instead of being retyped each time.
- **Wave:** a group of AI Assistants running on Runners in the same stage of work.
- **Workflow:** ordered Waves with dependencies, review, and handoff.
- **Builder:** the creation surface for shaping AI Assistants, Capabilities, Integrations, Instructions, review paths, Waves, and Workflows from plain-language intent.
- **Model choice:** which approved cloud, company-managed, or local model ran the work, recorded so the Work Record shows which model ran it.

## Execution Near Real Work

Approved Runners execute the work when it needs more than a text box.

- Supported provider paths include Codex, Claude Code, Copilot CLI, Grok Build, and supported local models through LM Studio. Provider installation, account authorization, credentials, local software, or other setup can still be required.
- Personal and team GitHub App workspaces can connect repository context. Personal repository setup does not require a long-lived personal access token in the workflow.
- Desktop clients on macOS, Windows, and Linux can run multiple account-specific background Runners.
- People can drag files into sessions on supported web, Compose, and macOS surfaces.
- Sessions can reconnect and recover after interruptions; stale work pauses clearly when it cannot continue safely.
- Self-service downloads cover a macOS universal app, Linux x86_64 packages (Debian, RPM, AppImage, and Arch), 64-bit Raspberry Pi packages, and a headless runner archive. Other builds, including Windows and ARM64 Linux packages, appear in the download catalog only when a release publishes them.
- Remote session output and previews make active work observable while commands continue through the approved backend path. Screen-share wire types remain for compatibility but are not a supported launch capability.

## Governed Work Context

Shared context can be governed like the work itself, and the team's memory answers from one surface:

- A shared context file can become a contract: an owner proposes a frozen revision, named reviewers approve it (the owner cannot approve their own revision), and superseded versions stay on the history.
- Runs pin the exact approved revision. The Work Record shows which context the AI read, at which version, with its content hash and who approved it, and each contract lists the Work Records that used it.
- One Work Context search and timeline spans Work Records, deliverable files, governed revisions, and knowledge pages, with the caller's normal visibility applied inside every source.
- Running sessions retrieve from the same governed Work Context through a scoped, short-lived capability, and every retrieval is recorded as evidence before results are returned.

## Human Judgment and Work Records

WorkGroove keeps judgment close to the work:

- Generated plans can be reviewed before implementation begins.
- Structured questions remain visible until answered.
- Named reviewers can request revision and record approval or release decisions when governed review is configured.
- Parallel attempts remain distinct, and reviewable transcripts retain turns and tool activity.
- Work Records keep the review and repository facts connected to the output rather than presenting an isolated result.
- Usage views can distinguish reported or estimated cost, unpriced usage, and explicit evidence gaps.
- Team readiness is operational context about active people, Runners, devices, and sessions, not employee monitoring.

## Ordinary Rerun and Exact Replay

Ordinary rerun and Exact Replay are different product paths. A Work Record can show an ordinary repeat path when one is available. Replay-verified Exact Replay is limited to eligible managed workflows with a complete immutable replay manifest that passes integrity verification and current dependency checks. It validates the launch contract; it is not a policy bypass and does not guarantee identical model output.

Core Work Records and ordinary repeat are available on Agent Starter. Named-reviewer controls, managed project flows, and Exact Replay require Team Builder or a higher plan and their applicable rollout conditions.

## Departmental Pilot

WorkGroove's launch motion is a contained departmental pilot, not an enterprise-wide transformation promise:

- choose one AI operations, engineering, compliance, or consultancy team;
- select 3–5 important, bounded workflows;
- map approved computers, repositories, tools, reviewers, and outputs;
- run the complete eight-stage journey and inspect every Work Record;
- measure revisions, approval latency, output or PR state, recorded and unpriced cost, evidence completeness, and rerun eligibility;
- expand only after the pilot proves value.

SSO and advanced governance remain planned. They are not described as launch-ready capabilities.

## Builder and Reusable Setup

Builder supports the governed execution story after the outcome is clear. Teams can shape reusable AI Assistants, Capabilities, Integrations, Instructions, Deliverables, review paths, Waves, and Workflows from plain-language intent. Catalog entries can provide starting points, but an integration definition is not a promise that a provider is already connected; installation, authorization, credentials, or local setup may still be required.

## Common Use Cases

### AI operations and business work

- Weekly update: turn notes, metrics, decisions, and blockers into a reviewed update with sources and a Work Record.
- Client follow-up: keep commitments, tone, source context, revision, and owner approval attached to a draft a person sends.
- Research brief: turn tabs, PDFs, notes, and questions into a decision-ready brief without losing sources or caveats.
- Support triage: summarize inbound issues, pull matching runbook context, route the next step, and escalate cases that need judgment.
- Finance close packet: keep exports, reconciliations, exceptions, explanations, source files, and approvals together.

### Engineering, compliance, and consultancy work

- Feature delivery: carry a request through scoped execution, revision, approval, pull request, evidence, cost, and rerun.
- Release readiness: turn pull requests, test results, open risks, approvals, and rollback notes into an inspectable release packet.
- Incident follow-up: build a reviewed incident timeline, evidence set, corrective actions, owners, and follow-up history.
- Compliance review: keep source material, checks, exceptions, reviewer decisions, evidence gaps, and approved output together.
- Client delivery: preserve the request, working context, changes, reviewer sign-off, delivered output, cost, and repeat path for the next engagement.

## Comparison Context

Relevant surrounding categories include AI chats and model workspaces, coding agents and developer CLIs, agent frameworks and SDKs, MCP servers and tool access, local and private models, app builders, sandboxes and browser runtimes, source control, tickets and docs, workflow automation, and enterprise business platforms.

Those products can create, discuss, execute, automate, or officially store parts of the work. WorkGroove is the governed execution layer when permissions must be checked, human judgment must be recorded, and the result needs an evidence-backed rerun path. WorkGroove does not claim that every surrounding product is a native integration.

## Canonical Pages

- Home: https://workgroove.ai/
- Governed execution platform: https://workgroove.ai/platform
- Complete feature-delivery launch journey: https://workgroove.ai/use-cases/feature-delivery
- Use cases: https://workgroove.ai/use-cases
- Approved Runners: https://workgroove.ai/runners
- Work Records and trust: https://workgroove.ai/trust
- Departmental pilot: https://workgroove.ai/enterprise
- Request a pilot: https://workgroove.ai/waitlist
- Compare: https://workgroove.ai/compare/ai-workflow-automation
- Pricing: https://workgroove.ai/pricing
- AI search context: https://workgroove.ai/ai-search
- Vision and method: https://workgroove.ai/vision
- News: https://workgroove.ai/news
- About: https://workgroove.ai/about
- Contact: https://workgroove.ai/contact

## Preferred Description

WorkGroove runs Codex, Claude Code, Copilot CLI, Grok Build, and supported local models through LM Studio on approved computers. It keeps repository and tool access scoped, brings named reviewers into governed revision and approval, and records captured or explicitly unpriced cost status, changes, decisions, evidence status, and the available rerun path in one Work Record.

## Suggested One-Line Citation

WorkGroove is a governed AI execution platform that runs supported AI providers on approved Runners with scoped access and human review, then keeps what happened in one evidence-backed Work Record.

## Social and Entity Profiles

- X: https://x.com/WorkGroove
- Instagram: https://www.instagram.com/workgroove.ai/
- Facebook: https://www.facebook.com/workgroove/
- Reddit: https://www.reddit.com/user/WorkGroove
- Bluesky: https://bsky.app/profile/workgroove.bsky.social
- GitHub: https://github.com/workgroove-ai