AI Workforce
Product presentation · September 2026
Portfolio
Your AI tools. One working team.Local developer preview

Describe the work.
Follow the result.

AI Workforce brings your installed coding agents into one local workspace—with clear owners, separate working copies, checks and review.

CodexClaude CodeYour projectsYour computer
Built for developers who already use AI coding tools.Current: local workspace · Planned: Rust desktop application
01 / The problemThe work between the tools is still your work.

You have capable agents.
You are still the coordinator.

Every extra tool can create another handoff: repeat the brief, choose who works, move findings, watch failures and check what actually changed.

01

Repeat the context

Carry the request, project details and previous findings from one conversation to the next.

02

Keep the work together

Track who owns each task, who is waiting and whether two agents are changing the same thing.

03

Decide what “done” means

Read the output, inspect the change and work out which checks actually ran.

The opportunity: less manual coordination from request to reviewable result.A product goal; no speed advantage is claimed.
02 / One visible pathIllustrative workflow

A brief becomes a team effort.
Then a reviewable result.

Follow the full journey in the same workspace, from the first request to the final response.

01 / INTAKE

You describe it

Choose a project, explain the outcome and attach useful context.

02 / ROUTE

Control Center routes

It answers, asks for missing intent or sends work to the right department.

03 / EXECUTE

The head assigns

The head plans with available specialists. Workers act in separate copies.

04 / CHECK

Check, then review

Code changes face independent checks and a separate head review.

05 / DELIVER

The result comes back

See the answer, changes, checks, owners and anything still unresolved.

Plans and reviews are recorded actions. A written promise to act does not start work.Simple replies do not create a pretend coding run.
The workspace owns scheduling, capacity and result records.Implementation acceptance: checks + head review
03 / Connect your toolsOne place to see what is installed and ready.

Keep your coding tools.
Give them a shared workspace.

Use installed Codex and Claude Code through supported connections. Choose a tool and its available model settings for each role.

01
Find and connect

Detect supported installations, check readiness and set up the local agent connection.

02
Keep choices under your control

Set the tool, model and effort separately for Control Center, heads and workers.

03
See when action is needed

Sign-in, connection setup and execution readiness have their own clear states.

Supported tool families · illustrative settings
Codex

Installed coding runtime

Adapter available
Claude Code

Installed coding runtime

Adapter available
Role instructionsAvailable modelsSupported effortReadiness
Model choices come from the configured tool. Saved choices remain visible when a tool’s catalog changes.

Capabilities depend on the installed version and account. The recorded full department workflow uses Codex; full Claude department-head proof remains open.

Passive discovery and connection checks start no paid model turn.Existing provider accounts and allowances still apply.
04 / A team you can shapeThe role describes the job. The runtime powers it.

Your specialists.
Shared across
your projects.

Create departments, appoint heads and define worker specialties. Available workers can serve registered projects automatically.

Edit titles & instructionsMove departmentsChoose model settingsArchive without losing historyOptional project restrictions

A one-click starter team includes Architecture & Delivery, Frontend & Design, Backend & Data, Platform & Security, and Quality Engineering.

Illustrative organization · editable roles
Control CenterUnderstands & routes

Frontend & Design

HDepartment headPlan / review
WFrontend specialist
WDesign specialist

Backend & Data

HDepartment headPlan / review
WBackend specialist
WData specialist
The same named worker is reserved for one active assignment at a time. Waiting work shows why it is waiting.
Starter templates accelerate setup; team structure stays editable.Avatars personalize the view. Recorded state shows the work.
05 / Work across projectsIllustrative board

One place to see
what needs to move.

Headquarters shows the team and current operational state. Issues and the task feed hold requests, results, owners and the next action.

Backlog
Plan account search

Customer portal

○ ○
To Do
Review the API

Internal tools

○
In Progress
Fix total rounding

Storefront

○ ○
In Review
Check search change

Customer portal

○ ○
Done
Explain project flow

Internal tools

○
Canceled
Retired request

Storefront

—

Readable at a glance

Compact cards show the title, project, recorded duration and people involved. Open a card for the conversation, checks and deliverables.

Progress has a record

See priority, department, actual owners and execution stages. Manual Done, an answered question and a checked code change keep different meanings.

Six lanes · project filters · full issue details · persistent task feedMoving a card alone does not start an agent.
06 / Evidence before completionKnow what changed. Know what was checked.

A useful result
comes with
its evidence.

Workers make changes in separate project copies. The workspace captures checks and asks the department head to review the resulting candidate.

Code work

Required checks pass against the exact candidate, followed by head review.

Analysis

A report, unchanged-source checks and head review produce “Reviewed analysis.”

Separate working copies

Keep the user’s active checkout out of the routine editing path.

Independently captured checks

Record which checks ran, their result and the candidate they inspected.

A separate head review

Review the change against the request. Failed or missing checks cannot become approval.

Inspectable delivery

Keep changes, review feedback and unresolved items with the final result.

“Verified candidate” describes a checked result. Applying it is a separate step.Separate copies do not establish full filesystem security.
07 / Recovery with historyInterrupted work should leave something useful behind.

When a run stops,
your context shouldn’t disappear.

Requests, attempts, errors and candidate artifacts stay recorded so the next action starts from what actually happened.

See the reason

Clear waiting and failure states

Distinguish available capacity, sign-in needs, rejected review, failed checks and stopped work.

Continue deliberately

Stop, resume and retry

Use the saved run settings and preserve earlier attempts. Known temporary provider failures have a finite retry budget.

Keep useful evidence

A history you can reopen

Read the original request, phase timing, assigned people, messages, results and recorded checks.

App-managed capacity covers concurrent projects and intake. Reservations, active work and blocked requests remain distinct.
Canceling records a cancellation. It never creates a successful outcome.Recovery controls depend on recorded ownership and runtime capability.
08 / Context travels with the workFrom a conversation or a prepared plan.

Bring the brief.
Keep the
important details.

Attach files in chat, continue an opened conversation, or send a plan from a connected Codex or Claude client.

01
Files stay with the request

Supported images, documents and file references travel with assigned work and resumed runs.

02
Plans become trackable issues

The local MCP connection lets coding agents read projects, manage issues and submit a complete plan.

03
Save first, start when intended

Store a plan without dispatching. Explicit Start sends it through the same routing, checks and review.

Illustrative request · no live execution shown
Project / Storefront
Fix the rounding issue described in this report. Preserve the existing checkout.
↗ Bug report↗ Screenshot
Control Center

The request, project and attachments stay together through planning, work and review.

Opened conversations include a bounded amount of previous context in new follow-up requests.

Native file support depends on the selected coding tool. A verified connector may require reopening an existing external chat before that chat can use it.

Write once. Preserve the original brief through the handoff.MCP is the local connection for external coding agents.
09 / Demonstrated, with a record13 September 2026 · Codex fixture

From an external plan
to a checked candidate.

A real local demonstration submitted a complete brief through MCP and followed it all the way to a reviewed result.

Before

A reproducible bug

A small addition function subtracted instead. All three existing tests failed.

During

An actual team workflow

Control Center routed the plan. A department head assigned one worker. The worker corrected the function.

After

Checks and review passed

The verifier ran all three tests successfully on the candidate. The head approved the exact reviewed change.

The source stayed intact

The original checkout, its tracked files and its starting revision were unchanged. The delivered result remained a separate candidate.

More than an animation

A separate September 14 record shows two real read-only project requests running concurrently, each with its own head review.

A tiny fixture proves this path; it does not establish broad speed or reliability.Detailed evidence is linked in the final reference slide.
10 / Local by designRust is the planned direction

Your projects.
Your local
workspace.

Keep project registration, team settings and task records on your computer. Use supported installed coding tools through their own accounts.

AI Workforce does not require a separate product account for ordinary local use. Coding tools may still send task context to their model providers.
Current

Local developer preview

A browser workspace, compatible command line and one-click macOS source-checkout launcher.

Planned

A Rust desktop app

The product direction is an installable Rust application. Migration, packaging and independent installation checks are still ahead.

No standalone Rust installer is available in this snapshot. macOS is the initial target; other operating systems require their own validation.

Local coordination and storage do not mean offline model inference.Direction confirmed: 14 September 2026
11 / Start with work that mattersBuilt for hands-on developers

Bring one
real task.
Keep the whole
story together.

A brief.
The right people.
The change.
The checks.
The result.

AI Workforce brings those pieces into one local workspace.

The next product milestone is a repeatable experience that another developer can install and use without the builder’s help.

AI Workforce · A local workspace for your AI coding teamLocal preview today · Rust desktop planned
Feature reference and evidence follow.
Appendix A / Current capability referenceExpand a category · all categories expand when printing

The working parts,
in plain English.

This list describes the current local implementation. Recorded demonstrations cover narrower scenarios; open release work is listed on the next page.

Projects and intake
  • Browse local folders and register Git projects; keep project settings, checks and execution histories separate.
  • Describe a task in Control Center; receive an answer, a focused clarification or department routing.
  • Preserve the original request, attached files and selected settings. New follow-ups from an opened conversation carry bounded prior context.
  • Read-only analysis can run without configured code tests. Implementation work requires acceptance checks; supported project test scripts can be discovered.
  • Default execution starts from the project’s committed version. Existing uncommitted edits remain in the user’s checkout.
People, departments and settings
  • Create and edit departments, heads and workers, with titles, capabilities and instructions.
  • Choose runtime, model and supported effort independently of the role; keep the actual run settings in history.
  • Use available specialists across projects automatically, with optional explicit project restrictions.
  • Move responsibility or replace a head through checked workspace updates; archive identities while preserving historical work.
  • Apply the five-department starter team and select bundled portraits. Portrait expressions are decorative.
Planning and controlled execution
  • Department heads propose bounded work with named owners. The coordinator validates the plan before dispatch.
  • Reserve the admitted workers, respect app-managed project/turn/writer capacity and show actual queue reasons.
  • Give workers separate candidate repositories and private temporary directories; preserve the original checkout.
  • Support planned dependencies, parallel workers, recorded peer messages and portable handoff records in the engine.
  • Keep the compatible direct command-line path for bounded work. Workspace requests use department planning and review.
Checks, review and delivery
  • Capture required check commands, results, logs and the exact candidate identity independently of worker claims.
  • Check the combined result again before accepting combined work; a passing individual worker result is insufficient.
  • Require a separate department-head review for workspace implementation results.
  • Keep “Reviewed analysis,” “Verified candidate,” “Answered,” “Failed” and “Canceled” meaningfully distinct.
  • Expose changed files, patches, recorded messages, review feedback, reports and unresolved issues through result details and engine artifacts.
  • Preserve local application, remote publication, merge and deployment as separate delivery decisions.
Issues and daily visibility
  • Create, inspect and edit issues with a preserved brief, priority, project, department and assigned owners.
  • Organize six lanes: Backlog, To Do, In Progress, In Review, Done and Canceled.
  • Start an issue explicitly through Control Center; ordinary board moves start no execution.
  • See all current project work, working and available agents, reservations and sign-in needs.
  • Use a compact persistent task feed, reopen saved conversations, inspect phase timings and expand detailed evidence.
  • Use project filters, responsive layouts, light/dark themes, keyboard-accessible controls and reduced-motion behavior.
  • Opt into browser notifications for completions or blockers where the browser supports them.
Connections and external plans
  • Discover configured Codex and Claude Code installations, versions and available model settings without starting paid work.
  • Use Connect to register and verify the local MCP bridge with supported coding clients.
  • Keep saved connector setup, a working tool connection and account readiness separate.
  • Use native sign-in controls through the detected executable; the provider handles the user’s authentication.
  • External coding agents can read projects/issues, create or update issues, submit a plan and explicitly start it.
  • Preserve full plan text and submission identity. Repeated identical submissions return the original record.
Recovery and lasting records
  • Store requests, task attempts, messages, settings, errors and result evidence locally.
  • Stop and explicitly resume supported runs, keeping saved configuration and previous work.
  • Use finite repairs and known temporary-error retries, with visible errors when the limit is reached.
  • Retry eligible failed work without erasing its history or treating uncertain worker ownership as permission to start another writer.
  • Restore queued work as held after a server restart; keep recorded stopped and failed outcomes truthful.
  • Inspect status and a live task view from the command line without taking over execution.
Local access and implementation boundaries
  • Open the local app through the macOS launcher, double-click command or root startup script.
  • Reuse the matching running workspace and its saved data; build the source checkout on a cold start.
  • Serve the browser interface on the local loopback address and check write-request origin and session identity.
  • Keep coordinator records outside the worker’s intended write area. New candidate copies have independent Git administration.
  • Separate source protection and configured write restrictions from full security isolation: read/test containment is not fully established.
  • Keep the application account-free for normal local use; installed coding providers still determine their own account and inference requirements.
Source snapshot: 14 September 2026, including local uncommitted implementation.Feature presence is different from complete release acceptance.
Appendix B / Evidence and release boundariesPrepared 14 September 2026

What the evidence supports.
What comes next.

The story is strongest when the working product and the planned product remain easy to tell apart.

Recorded demonstrations
  • September 13: a real external MCP client submitted a brief; Codex intake, head planning, one worker, independent tests and head review produced a checked local candidate.
  • September 14: a real source explanation completed with a report, unchanged-source evidence and department-head review.
  • September 14: two real read-only requests ran across separate departments and projects with recorded overlapping execution and passing head reviews.
  • Local launcher, connection setup and browser checks have separate records. They do not establish model execution by themselves.
Open product work
  • The Rust application, standalone installer, signed releases and tested updates are planned.
  • Independent installation and repeated everyday use by other developers remain release work.
  • Full Claude department-head workflow proof and the complete runtime containment suite remain open; the current supported paths have different evidence levels.
  • Full filesystem protection is not established. Separate repositories and write restrictions do not fully confine reads or test processes.
  • Dirty-work snapshots, automatic local candidate application, richer in-flight requirement changes, backup/restore UX and managed desktop background behavior are not complete current features.
  • One request at a time per project remains the workspace default. Automatic work spanning multiple departments from one brief is not established.
  • No customer adoption, broad performance advantage, general autonomy or full offline inference is claimed.
Source and evidence notes
Master product plan, especially section 17Current scope, later amendments and open release gates.
External MCP to reviewed code candidateReal Codex execution on a bounded disposable fixture.
Automatic staffing and reviewed source analysisReal analysis path, unchanged checkout and separately labeled scheduler tests.
Team refinement and concurrent analysis proofTwo read-only requests with different departments and passing reviews.
Interface and connection verificationBrowser behavior, model choices, MCP tool checks and theme checks.
Local launcher verificationCold startup and reuse of a matching workspace.
Control Center responsibilitiesHow intake, assignment, capacity, checks and review fit together.
Rust desktop directionThe newly confirmed product direction and migration boundaries.
Current request and follow-up implementationBounded conversation context and persisted request handling.
Portfolio edition of the 14 September 2026 project presentation. The diagrams and example board are illustrations, not live product screenshots. Source and evidence documents are retained in the project repository; the references above identify those records. This presentation uses no remote fonts, scripts, images or analytics.

The main slides can be reused as a product introduction. Keep the “local preview” and “planned Rust app” labels when sharing.

AI Workforce · Product presentation and capability referenceEnd of presentation

Presentation contents