Trusted Local AI Actor Teams — Part 1: The Vision & Requirements

This is Part 1 of a two-part series. Part 1 sets out the vision and requirements for a trusted, local-first AI Actor orchestration platform. Part 2 takes these requirements to a real codebase decision — a gap analysis and business case: Trusted Local AI Actor Teams — Part 2: Codebase Gap Analysis & Business Case.

This is a concept and requirements document, shared for discussion. Version 1.0 · 3 July 2026.

The concept in one sentence Build a locally controlled system that can assemble a project team of specialised AI and human Actors, assign each Actor a clear role and model, coordinate their work through long-running review loops, and retain the project knowledge, prompts, costs and results under the user’s control.

Executive Summary

The platform should work less like a single chatbot and more like a well-managed team. A project begins with an outcome, budget, quality target and timeframe. An Orchestration Actor then determines what skills are needed, creates or selects suitable Actors, defines their responsibilities and boundaries, assigns models and tools, decomposes the project into tasks, and sequences the work.

An Actor is a participant in the workflow. An AI Actor is a persistent agent persona with a role, system prompt, capabilities, model, tools, memory, permissions and explicit limits. A Human Actor is a person who can provide knowledge, make decisions, test the experience, approve high-risk changes or perform work that should not be delegated. Both types of Actor can own tasks, receive handovers and contribute to the same project history.

Specialised, bounded Actors A JavaScript Actor may understand the whole system but be responsible only for JavaScript and frontend work. If it believes the database or Docker design must change, it must consult the responsible Actor rather than silently changing another domain.

Holistic oversight Actors Architecture, product, security and cost Actors periodically inspect the work as it develops. They can identify drift, pause a task, request revision, escalate to a stronger model or ask a Human Actor to decide.

A typical software team might contain a Product Owner, Business Analyst, Scrum Master, Architect, JavaScript Developer, API Developer, Database Developer, Infrastructure Engineer, Tester, Security Reviewer, Integration Reviewer and Cost Controller. Different Actors may use different local or cloud models. A small local model could classify tasks and maintain logs, a specialised coding model could implement modules, and a stronger reasoning model could be reserved for architecture, difficult reviews and course correction.

The key is not simply having several models talk to one another. The value comes from carefully engineered personas, clear scope boundaries, structured handovers, repeated critique and the ability to stop work that is moving off course. The platform should support long-running cycles such as:

Example delivery loop Define → Research → Plan → Design → Build → Test → Critique → Correct → Integrate → Retest → Human review → Release

During delivery, scheduled or event-triggered watchdog Actors can read changed code and project records. An Architecture Watchdog checks whether implementation still follows the design. A Scope Watchdog checks whether the work still serves the intended user. A Cost Watchdog checks token usage, model selection, retries and wasted effort. These Actors normally begin with read-only access, but can flag, pause or redirect work when agreed thresholds are reached.

The orchestration engine, Actor definitions, project memory, task state, prompts, logs, intermediate artefacts and final results must remain locally controlled. External model providers may be used selectively, but they are optional processing resources, not the owners of the workflow. The local system decides what context is necessary, what may leave the environment, what must remain private and what is stored afterwards.

Why it is valuable to us It makes practical use of our local AI machines, reduces dependence on expensive frontier models, allows cheaper models to perform bounded work, and uses stronger models only where their judgement adds value. Better review loops should reduce rework and token waste.

Why it is valuable to others Individuals, community groups and organisations could gain a configurable “team” of perhaps ten specialised Actors without hiring ten full-time people. We could help them deploy, adapt and improve their own system while they retain ownership of their data and workflows.

The platform must be genuinely open source. Essential capabilities such as orchestration, scheduling, prompt inspection, memory, task management, approvals, cost tracking, workflow resumption and export must not depend on a proprietary hosted control plane. Commercial value can come from consulting, integration, training, support and the design of high-quality Actor teams, rather than locking customers into a closed platform.

Simple example A client asks for a volunteer-management application. The Orchestration Actor creates the team and plan. The Business Analyst researches requirements; the Product Owner prioritises value and budget; the Architect defines interfaces; separate JavaScript, API, database and infrastructure Actors build their parts; Tester and Reviewer Actors repeatedly critique the work; Human Actors test the experience and approve key decisions. The system keeps the shared memory, prompts, decisions, costs and final assets locally, even when selected tasks use cloud models.

In practical terms, the proposition is: imagine having a dedicated team of specialised people, each instructed to perform a particular kind of work in a particular way, while a project manager, architect, reviewers and human decision-makers keep the whole effort aligned. This platform would create and coordinate the AI equivalent of that team, while allowing humans to remain active participants whenever judgement, lived experience, accountability or approval is required.

What makes it different Actors have both responsibilities and exclusions. They can consult one another, hand work across defined interfaces, run for long periods, be interrupted by watchdogs and improve through versioned personas and evaluated role memory.

Non-negotiable foundations The full control plane is open source; local and cloud models can be mixed; prompts and model requests are inspectable; humans participate as Actors; and workflows, memories, artefacts and costs remain portable and locally controlled.

The practical opportunity is therefore larger than a coding tool. It is a reusable way to organise AI work for ourselves and to help other people establish their own capable, governed teams. The system may run on a local machine, in a client-controlled cloud environment, or as a hybrid, but the client retains control of the team, knowledge and workflow.

Document Structure

The remainder of this document expands the concept into a set of design principles, functional requirements, governance requirements, use cases and implementation priorities. Word’s Navigation Pane can be used to move between headings.

• 1. Purpose and vision
• 2. Terminology and conceptual model
• 3. Problem statement
• 4. Operating principles
• 5. Actor model
• 6. Team formation and work decomposition
• 7. Workflow orchestration and long-running execution
• 8. Review, critique and course correction
• 9. Model and provider routing
• 10. Memory, learning and persona improvement
• 11. Trusted data handling and privacy
• 12. Human Actors and human-in-the-loop governance
• 13. Local-first architecture
• 14. Open-source and anti-lock-in requirements
• 15. Agile, Kanban and work management
• 16. Cost, time, quality and value governance
• 17. Security and permissions
• 18. Transparency, observability and audit
• 19. Example applications
• 20. Consulting and service model
• 21. Consolidated functional requirements
• 22. Non-functional requirements
• 23. Suggested minimum viable platform
• 24. Measures of success
• Appendix A. Example Actor profiles
• Appendix B. Example software delivery workflow
• Appendix C. Open-source project evaluation checklist

1. Purpose and Vision

The purpose of this document is to define a platform that organises artificial intelligence into durable, understandable teams rather than treating AI as a single undifferentiated assistant. The platform should allow an individual or organisation to describe an outcome, then create a governed team of AI and Human Actors that can plan, research, build, test, review and improve the work over time.

The vision is a trusted, local-first orchestration environment in which users retain control of the operational engine, prompts, memory, project state and outputs. Local models and cloud models can be combined deliberately. Each model is selected because it is suitable for a role, not because the entire platform belongs to that model provider.

Vision statement Make advanced AI teamwork accessible to individuals, communities and organisations by providing a locally controlled, fully open-source system that can build and coordinate specialised Actor teams, preserve human control and deliver useful work at a governed cost.

1.1 Intended outcomes

• Better work decomposition. Break broad projects into tasks that can be assigned, reviewed and completed without giving every model the entire problem.
• Higher-quality output. Use specialist Actors, independent reviewers and repeated correction loops instead of trusting a single response.
• Lower and more predictable cost. Use local and lower-cost models for routine work and reserve expensive reasoning models for decisions where they add real value.
• Local ownership. Keep project state, prompts, memories, artefacts and audit records under the user’s control.
• Human participation. Allow people to be active Actors within the same workflow, not merely emergency approvers outside it.
• Reusable capability. Improve Actor personas and workflows over time so that the team itself becomes a valuable asset.
• Practical transfer. Make it possible to help another person or organisation deploy their own system without forcing them into a proprietary platform.

2. Terminology and Conceptual Model

2.1 Actor

An Actor is a named participant that can receive responsibility, perform work, communicate with other participants and produce an auditable result. Actors can be artificial or human. The term is deliberately broader than “agent” because the workflow may include people, automated services and AI personas as peers in the delivery process.

This usage is related to the general idea of an actor in systems modelling, but it is more operational. An Actor is not merely a diagram symbol. It has identity, responsibilities, capabilities, permissions, work history and relationships with other Actors.

2.2 AI Actor

An AI Actor is a persistent agent persona backed by one or more language models and tools. It has a role, goal, system instructions, task boundaries, memory access, approved tools, model settings, cost limits and escalation rules. It may reason, call tools, write files, inspect artefacts, communicate with other Actors and update project state according to its permissions.

2.3 Human Actor

A Human Actor is a person represented within the same orchestration model. A Human Actor may own tasks, supply domain knowledge, review outputs, test user experience, approve expenditure, resolve disagreements, perform physical-world actions or accept accountability for a decision. Human work and feedback should be captured as part of the project record.

2.4 Orchestration Actor

The Orchestration Actor is responsible for forming the team and coordinating delivery. It may create or adapt Actor personas, generate project-specific prompts, select models, allocate tasks, schedule checks, monitor progress and route disputes or risks to the appropriate Actor. The Orchestration Actor itself must operate under policies, budgets and human governance; it is not an unrestricted super-agent.

2.5 Persona

A persona is the engineered operating definition of an AI Actor. It includes the role’s behaviour, expertise, standards, boundaries, decision rules, examples, tools and required output formats. Persona engineering is a core part of the platform because the reliability of the team depends on more than model capability alone.

2.6 Team, workflow and project memory

Term	** Meaning**
Actor team	A set of AI and Human Actors assembled for an outcome, with defined responsibilities and communication paths.
Workflow	The executable sequence, graph or set of rules that routes tasks, artefacts, reviews, pauses and approvals.
Project memory	The locally retained requirements, decisions, facts, terminology, risks, artefacts and lessons relevant to one project.
Actor-role memory	Reusable lessons and examples relevant to a particular kind of Actor across projects.
Organisation memory	Policies, standards, templates, preferred technologies and institutional knowledge that may be shared across approved projects.
Artefact	A work product such as code, a design, a report, a test result, a decision record or a deployment package.

3. Problem Statement

Most AI work today is still organised as a conversation with one general-purpose model. Even when tools or sub-agents are available, the main model often remains responsible for understanding the entire objective, deciding the architecture, producing the implementation, reviewing itself and remembering the history. This creates several predictable weaknesses.

• A model can solve a local task while unintentionally damaging the wider design.
• The same model that made an assumption may reproduce that assumption when asked to review its own work.
• Long tasks can drift from the original objective as context is summarised, truncated or replaced.
• Expensive models may be used for work that a smaller local model could complete adequately.
• Unbounded agents can change unrelated files or cross responsibility boundaries without consultation.
• Repeated retries can consume substantial tokens without any independent assessment of whether the approach is still sensible.
• Prompts, traces, memories and project history are frequently distributed across provider platforms rather than retained as a coherent local asset.
• Humans are often treated as external approvers rather than participants who can own and complete work inside the workflow.

The platform addresses these weaknesses by combining specialisation with oversight. Narrow Actors perform bounded work. Broader Actors maintain architectural, product, security and financial awareness. Human Actors contribute judgement and lived experience. The orchestration engine coordinates these contributions and preserves the record.

4. Operating Principles

Principle	** Meaning**
Local control is the default	The user controls the orchestration engine, state, memories, prompts, records and outputs.
Specialise without creating silos	Actors receive clear responsibility but enough project context to understand how their work connects to the whole.
Boundaries are explicit	Every Actor is told what it may do, what it must not do and when it must consult another Actor.
Review is independent	Important work is assessed by a different Actor, model or Human Actor wherever practical.
Humans are first-class participants	People can be assigned tasks and decisions in the same workflow as AI Actors.
Escalation is normal	Uncertainty, disagreement and risk should trigger consultation rather than hidden improvisation.
Use the least expensive sufficient model	Model choice should reflect task requirements, privacy and reliability.
Trust is inspectable	The system earns trust through transparency, constrained permissions, reproducibility and audit, not through branding.
Open source includes the control plane	Essential orchestration and governance cannot be withheld behind a mandatory commercial service.
The team should improve	Prompts, examples, procedures and evaluations should be versioned and refined from project experience.

5. Actor Model

5.1 Required Actor definition

Each AI Actor should be defined as a versioned profile that can be reused, cloned or adapted. The platform should distinguish between general capabilities and project-specific instructions. A database specialist may be a permanent reusable Actor, while its task prompt and access to a particular schema are project-specific.

Area	** Required content**
Identity	Name, role, description and version.
Purpose	The outcome the Actor is responsible for producing.
Responsibilities	Work the Actor should perform independently.
Exclusions	Work the Actor must not perform without consultation or approval.
Consultation rules	Which Actors must be contacted when boundaries are crossed.
System instructions	Persistent operating behaviour, reasoning guidance, standards and output conventions.
Project instructions	Context, objectives and constraints specific to the current project.
Model profile	Provider, endpoint, model, parameters, context limits and fallback models.
Tools and skills	Approved functions, code execution, retrieval, filesystems, APIs and repeatable procedures.
Memory access	Project, role, organisation and task memory permissions.
Security permissions	Read, write, execute, network, secrets, deployment and destructive-action permissions.
Budget	Token, financial, elapsed-time and iteration limits.
Quality criteria	Acceptance tests, review standards and evidence requirements.
Escalation	Conditions requiring a reviewer, stronger model or Human Actor.
Audit settings	Prompt capture, tool logs, artefacts, model metadata and decision records.

5.2 Responsibilities and exclusions

A capable Actor should be able to understand adjacent domains without automatically taking ownership of them. This distinction is crucial. The JavaScript Actor may need to understand API contracts and database concepts, but its default authority remains the JavaScript and frontend layer.

Example boundary instruction You are responsible for JavaScript and frontend implementation. You may inspect API, database and infrastructure artefacts to understand their interfaces. Do not independently redesign those layers. When your task requires an external change, produce a structured change request for the responsible Actor and wait for approval or an updated contract.

Boundary rules reduce architectural drift, but they must not prevent useful initiative. An Actor should be allowed to identify a problem, explain why another component may need to change and propose options. The restriction is on making the cross-domain change without coordination, not on recognising the issue.

5.3 Human Actor profiles

Human Actors should also have profiles, though they need not be as detailed as AI personas. A profile may record the person’s role, authority, availability, preferred notification method, required approvals and areas of expertise. The platform should never infer that a human has approved work merely because a deadline has passed.

Human Actor example	** Possible responsibilities**
Product owner	Define value, priorities, acceptance criteria and trade-offs.
Domain expert	Provide facts, terminology, exceptions and real-world constraints.
User tester	Try the experience, report confusion and confirm whether it solves the intended problem.
Technical approver	Approve architecture, security controls, deployments or destructive operations.
Project sponsor	Set budget, timeframe and stop/go decisions.
Service operator	Perform actions involving physical systems, credentials or organisational authority.

5.4 Actor creation and retirement

The Orchestration Actor should be able to recommend new Actors when a project requires a capability not present in the current team. New Actors may be created from templates, derived from an existing Actor or generated as temporary project specialists. Creation should record why the Actor is required, what model and knowledge it will use, what it may access and how its work will be reviewed.

Temporary Actors should be retired or archived when their purpose is complete. Their useful lessons may be promoted into a reusable persona only after review. This prevents a growing collection of poorly understood agents with overlapping authority.

6. Team Formation and Work Decomposition

6.1 Team formation process

1. Clarify the outcome. Establish the intended user, value, deliverables, constraints, timeframe and budget.

2. Assess risk and privacy. Determine which information can remain local, which may be shared and which actions require human approval.

3. Identify capabilities. List the skills, knowledge and tools needed to deliver the outcome.

4. Select or create Actors. Reuse proven personas where possible and create new specialists only where necessary.

5. Assign models. Choose the least expensive model that is sufficiently capable, private and reliable for each role.

6. Define boundaries and interfaces. Specify responsibilities, exclusions, artefact contracts and consultation paths.

7. Build the workflow. Sequence tasks, reviews, approvals, monitoring and release stages.

8. Establish success measures. Define acceptance criteria, cost limits, quality thresholds and stop conditions.

6.2 Work hierarchy

Level	** Purpose**	** Example**
Outcome	The value to be delivered.	A usable volunteer-management service.
Capability	A broad area the solution must support.	Shift rostering.
Epic	A substantial body of related work.	Create and publish roster.
Story	A user-centred requirement.	As a volunteer, I can see my assigned shifts.
Task	A bounded piece of work assigned to an Actor.	Implement the roster API endpoint.
Subtask	A small verifiable action.	Add pagination and tests.
Review	Independent assessment of the artefact.	API reviewer verifies contract and error handling.
Approval	A decision allowing progression.	Human Product Owner accepts the story.

6.3 Interface contracts

When separate Actors own different components, the interfaces between them must be explicit. The platform should support contracts such as API specifications, event schemas, database migration requests, design tokens, acceptance criteria and test fixtures. An Actor should work against an approved contract rather than relying on an informal conversational assumption.

7. Workflow Orchestration and Long-Running Execution

The workflow engine should support projects that continue for hours, days or weeks. A workflow must be durable: it can pause, survive a restart, wait for a Human Actor, resume from a checkpoint and preserve every completed artefact without beginning again.

7.1 Required workflow patterns

Pattern	** Purpose**
Sequential	Pass a task through ordered stages.
Parallel	Allow independent Actors to work simultaneously.
Conditional branch	Choose the next step based on a test, score, risk or human decision.
Critique and revision loop	Return work to its owner until criteria are met or a stop condition is reached.
Voting or comparative review	Ask several Actors or models to assess alternatives.
Escalation	Route a difficult or risky decision to a stronger model or Human Actor.
Scheduled check	Run an oversight Actor at intervals or milestones.
Event-triggered check	Run when code changes, tests fail, cost rises or a task changes state.
Human approval gate	Pause until an authorised Human Actor approves, rejects or modifies the work.
Sub-workflow	Invoke a reusable workflow for testing, security review or release.
Checkpoint and resume	Persist state and continue after interruption.
Budget stop	Pause or terminate when time, token or cost limits are reached.

7.2 Scheduling and cron-style work

Long-running oversight may be implemented through schedules, queue events or repository events. The requirement is functional rather than tied to cron itself. The system must be able to initiate a check periodically, after a defined number of changes, before a release or when a threshold is crossed.

• Review changed files every thirty minutes while a coding task is active.
• Run integration tests after each completed module.
• Assess architecture drift after every five accepted tasks.
• Recalculate projected cloud spend each hour.
• Ask a Human Actor to test the interface before a story can be marked complete.
• Run a final independent review before creating a release candidate.

7.3 Pause, intervention and recovery

An oversight Actor must be able to recommend or initiate a pause when policy allows. Pausing should preserve the working state, explain the reason, identify affected tasks and present a route forward. The responsible Actor should not simply continue in a separate hidden run.

8. Review, Critique and Course Correction

Repeated critique is a defining feature of the platform. The goal is not endless debate. Reviews should be attached to explicit standards and stop conditions so that they produce correction rather than unbounded conversation.

8.1 Review outcomes

• Approved. The artefact meets its acceptance criteria and may progress.
• Approved with minor changes. The work can progress after small, clearly specified corrections.
• Revision required. The responsible Actor must address identified defects and resubmit.
• Clarification required. The reviewer cannot assess the work without additional information.
• Escalation required. The issue requires a stronger model, another specialist or a Human Actor.
• Stopped. The approach is unsafe, unaffordable or fundamentally inconsistent with the project.

8.2 Watchdog Actors

Watchdog	** What it inspects**	** Possible intervention**
Architecture	Changed files, dependencies, boundaries and design decisions.	Flag drift, request architectural review or pause conflicting work.
Scope and product	Stories, outputs and user value.	Reject work that is technically impressive but outside the agreed outcome.
Security	Permissions, secrets, dependencies, data flow and risky code.	Require remediation or human security approval.
Integration	Contracts between modules and concurrent branches.	Prevent incompatible components from progressing.
Quality	Tests, defects, duplication, maintainability and evidence.	Return work for correction or additional tests.
Cost and efficiency	Tokens, retries, provider costs, elapsed time and repeated work.	Switch model, reduce context, stop retries or request human review.
Privacy and disclosure	Context prepared for external providers.	Remove unnecessary information or require local processing.

8.3 Preventing reviewer loops

The system should prevent two Actors from endlessly returning work to each other. Every loop requires a maximum iteration count, accumulated cost limit and escalation rule. If the same defect recurs, the workflow should change approach, introduce another reviewer or ask a Human Actor to decide.

9. Model and Provider Routing

Model selection should occur at the Actor or task level. The system must support local inference, remote endpoints and cloud APIs without forcing all Actors to use the same provider. An Actor may also have a primary model and one or more approved fallbacks.

9.1 Model selection factors

• Capability and demonstrated performance on the task type.
• Specialisation, including coding language, SQL, testing, security or document analysis.
• Context-window size and quality at long context.
• Tool-calling and structured-output reliability.
• Local hardware requirements and inference speed.
• Provider price and token accounting.
• Data sensitivity and contractual restrictions.
• Availability, rate limits and latency.
• Licence and permitted use.
• The value of using a different model for independent review.

9.2 Example model allocation

Actor	** Possible model strategy**	** Reason**
Task classifier	Small local model	Routine structured classification at negligible marginal cost.
JavaScript Developer	Specialised local coding model	High-volume implementation close to the repository.
Database Developer	SQL-focused local or hosted model	Narrow expertise may outperform a larger general model.
Architect	Stronger reasoning model	Higher-value decisions justify greater capability.
Code Reviewer	Different model family from the developer	Reduces correlated assumptions and blind spots.
Cost Controller	Small local model plus deterministic calculations	Reasoning is modest and arithmetic should be tool based.
Privacy Reviewer	Local model only	Sensitive context should not leave the environment merely to decide whether it may leave.

9.3 Model discovery

The platform may inspect model catalogues such as Hugging Face or configured provider catalogues to identify suitable models. Recommendations should be evidence-based and locally reviewable. The system should not automatically download or execute an unfamiliar model without licence, security, size and compatibility checks.

10. Memory, Learning and Persona Improvement

The platform should improve primarily through versioned operating knowledge rather than uncontrolled self-modification. Actors can become more effective through better prompts, examples, checklists, tools, retrieval sources, evaluation cases and role memory. Changes should be proposed, tested and approved.

10.1 Memory types

Memory type	** Contents**	** Typical access**
Task memory	Immediate attempts, errors, inputs and outputs for one task.	Assigned Actor and reviewers.
Project memory	Requirements, decisions, terminology, interfaces, risks and accepted artefacts.	Approved project team.
Actor-role memory	Reusable lessons, failure patterns and preferred practices for a role.	Actors of that role and maintainers.
Organisation memory	Policies, standards, templates and institutional knowledge.	Role-based access.
Personal/private memory	Information intended for an individual user or tightly controlled group.	Explicitly authorised Actors only.
Audit memory	Immutable record of prompts, actions, approvals, model use and costs.	Auditors, administrators and authorised owners.

10.2 Improvement cycle

1. Record the task, Actor version, model, context, tools, outcome and review result.

2. Identify repeated failures, unnecessary cost or successful patterns.

3. Propose a change to the persona, workflow, example set or tool procedure.

4. Test the change against representative evaluation tasks.

5. Compare quality, cost, safety and speed with the previous version.

6. Approve, reject or revise the change through an authorised Actor.

7. Retain version history and the ability to roll back.

10.3 Shared learning without contamination

One Actor’s lesson should not automatically become a universal rule. Project-specific facts, personal information and temporary workarounds must not leak into organisation-wide memory. Promotion between memory layers should be deliberate and auditable.

11. Trusted Data Handling and Privacy

“Trusted” does not mean that every AI output is assumed to be correct or that any provider is assumed to be virtuous. It means the system provides inspectable controls over data, actions and disclosure. Users should be able to understand what is stored, what is sent externally, why it is sent and which Actor authorised it.

11.1 Data handling modes

Mode	** Description**	** Example**
Local-only	All processing and storage remain on the user’s machine or trusted local network.	Private journalling analysis or confidential source code.
Local-first hybrid	Project state remains local; selected tasks may call external models with minimised context.	Cloud architecture review using an abstracted design rather than the full repository.
Client-controlled cloud	The orchestration platform is deployed in infrastructure controlled by the client.	A small organisation uses its own cloud account and database.
Approved external service	A task uses a contracted provider under explicit policy.	A public document is summarised by a hosted model.

11.2 Disclosure controls

• Classify project data and artefacts by sensitivity.
• Allow Actors to access only the context required for their role.
• Preview the exact content prepared for a cloud provider.
• Remove secrets, personal data and irrelevant project history before transmission.
• Require approval for defined sensitive categories or destinations.
• Store the provider, model, request metadata and disclosure decision locally.
• Support a strict local-only mode in which all external model calls are disabled.

11.3 Personal and reflective use

The same platform may eventually support work beyond software, including personal research, reflective writing or exploration of sensitive life experiences. Such uses make local control and selective disclosure especially valuable. The platform should provide the capability without assuming that every user wants complete secrecy or that every cloud provider is inherently unsafe. The user should be able to decide and verify the policy.

12. Human Actors and Human-in-the-Loop Governance

Human participation is a core design feature, not a fallback for system failure. Some outcomes require lived experience, organisational authority, ethical judgement, physical action or legal accountability. The workflow should represent those contributions explicitly.

12.1 Human participation patterns

Pattern	** Example**
Clarification	A Human Actor answers a question that cannot be inferred from the project record.
Co-creation	A person and AI Actor jointly develop requirements, language or design.
User experience testing	A Human Actor tries the product and reports whether it is understandable and useful.
Approval	A person authorises expenditure, deployment, data disclosure or release.
Exception handling	A person resolves a novel situation that falls outside existing policy.
Accountable decision	A person accepts responsibility for a decision with material consequences.
Manual execution	A person performs a real-world action or uses credentials that should not be delegated.

12.2 Human experience as evidence

Automated tests can prove that a button works, but not necessarily that the experience makes sense. The system should be able to assign a Human Actor a test script, capture observations, ask follow-up questions and turn the feedback into accepted tasks. Human feedback should not be summarised away before decision-makers can inspect it.

12.3 Authority and accountability

Each approval gate should identify who has authority to decide. An AI Actor may recommend release, but the workflow can require a Human Product Owner or technical approver to accept it. Conversely, not every low-risk task needs human interruption. Policies should set proportional levels of autonomy.

13. Local-First Architecture

The platform should be deployable on an individual workstation, a local server, a private network or a client-controlled cloud environment. The same conceptual architecture should work across these deployment targets.

13.1 Core local components

Component	** Responsibility**
Actor registry	Stores versioned AI and Human Actor profiles.
Workflow engine	Executes tasks, branches, loops, schedules, pauses and approvals.
Task and project service	Maintains outcomes, stories, tasks, ownership, dependencies and status.
Model gateway	Routes approved requests to local and cloud model endpoints.
Prompt and context service	Builds visible model requests from personas, task context, memory and tools.
Memory service	Stores project, role, organisation and private memory with access controls.
Artefact store	Stores code, documents, test results, outputs and release packages.
Tool runtime	Runs approved tools in isolated environments.
Observability service	Records traces, costs, timings, failures, disclosures and decisions.
User interface and API	Allows people to create projects, inspect work, intervene and approve.

13.2 Suggested deployment pattern

Illustrative architecture Web interface and API → Local orchestration engine → Actor registry, workflow state and PostgreSQL → Local model gateway and optional cloud providers → Isolated tool containers → Local Git and artefact storage → Audit and cost records

This is a logical architecture rather than a prescribed technology stack. A first implementation might use Docker Compose, PostgreSQL, a local object store, Git worktrees, an OpenAI-compatible model gateway, Ollama or vLLM, and a web-based workflow interface.

14. Open-Source and Anti-Lock-in Requirements

The complete control plane must be available under a recognised open-source licence or a combination of compatible open-source licences. The platform should remain useful if every optional commercial service is removed.

14.1 Capabilities that must remain local and open

• Actor creation, editing and versioning.
• Workflow construction and execution.
• Scheduling and event triggers.
• Human tasks and approval gates.
• Prompt inspection and trace access.
• Project memory and artefact storage.
• Model routing and local endpoint support.
• Cost and token accounting.
• Pause, checkpoint, recovery and resumption.
• Export, backup and migration.
• Security policies and permissions.

14.2 Acceptable commercial services

Commercial hosting, implementation, support, training, managed upgrades, model access and consulting are compatible with the requirement. The unacceptable pattern is making a locally installed open-source framework dependent on a proprietary service for the essential orchestration, monitoring or governance functions that make the system practical.

14.3 Portability

Actor definitions, workflows, memories, prompts and project history should use documented formats and APIs. Users should be able to replace a model provider, storage layer or visual interface without losing the intellectual property accumulated in the system.

15. Agile, Kanban and Work Management

Agile methods provide a useful structure for sequencing Actor work, although the platform should not force every project into Scrum terminology. The important capabilities are visible work, bounded iterations, acceptance criteria, review and continuous reprioritisation.

15.1 Board capabilities

• Projects, outcomes, epics, stories, tasks and subtasks.
• Custom statuses such as Proposed, Ready, In Progress, Review, Human Test, Blocked and Done.
• Assignment to AI or Human Actors.
• Dependencies and blocking relationships.
• Acceptance criteria and definitions of ready and done.
• Budgets, estimates and actual costs.
• Links to prompts, runs, artefacts, tests and review decisions.
• Scheduled and recurring tasks.
• Audit history for status, ownership and scope changes.

15.2 Scrum-style iteration

A Scrum Master Actor may organise a planned iteration, but it should not merely generate ceremonies. It should check capacity, dependencies, unresolved decisions and review requirements. At the end of an iteration, the system should compare intended value with accepted output, identify failed assumptions and update the next plan.

16. Cost, Time, Quality and Value Governance

A project should begin with explicit priorities. “Fast”, “cheap”, “high quality”, “private”, “secure” and “complete” cannot always be maximised simultaneously. The Orchestration Actor should make these trade-offs visible and select models, reviews and iteration limits accordingly.

16.1 Governance dimensions

Dimension	** Questions**
Value	Does the work solve the user’s real problem?
Quality	Does it meet functional, maintainability and usability standards?
Time	Is progress consistent with the agreed timeframe?
Cost	Are model, infrastructure and human costs proportionate to the result?
Risk	What is the consequence of error, disclosure or failure?
Privacy	What information can leave the controlled environment?
Learning	Are successful practices being captured without spreading project-specific contamination?

16.2 Cost controls

• Set project, workflow, Actor and task budgets.
• Track local inference time as well as cloud expenditure.
• Record context size, output size, retries and failed calls.
• Estimate cost before invoking an expensive model.
• Use caching and reusable artefacts where appropriate.
• Detect repeated work and stalled critique loops.
• Allow a Cost Controller Actor to recommend a different model or workflow.
• Require Human Actor approval before exceeding agreed thresholds.

17. Security and Permissions

AI Actors should operate with the minimum access required. Model reasoning and tool authority must be separated. An Actor may be allowed to propose a shell command without being allowed to execute it, or to create a database migration without being allowed to run it against production.

Permission area	** Example controls**
Filesystem	Read-only paths, writable workspaces, protected files and deletion restrictions.
Code execution	Approved languages, container isolation, CPU, memory and time limits.
Network	No network, allowlisted destinations, proxy inspection or unrestricted access.
Models	Approved providers, local-only roles and per-Actor API credentials.
Secrets	No access, named secret access, use without disclosure or human-mediated use.
Databases	Read-only, migration creation, development write, production approval.
Git	Read repository, create branch, commit, open review request or merge.
Deployment	Build only, staging deploy, production approval or rollback.
Destructive action	Mandatory confirmation and reversible operation where possible.

18. Transparency, Observability and Audit

The user must be able to see how the system assembled a model request and how an outcome was produced. Showing only a friendly conversation transcript is insufficient for debugging or governance.

18.1 Required trace information

• Actor identity and profile version.
• Workflow and task version.
• Stored system instructions and project instructions.
• Memory and retrieved material included in context.
• Tool definitions made available to the model.
• The final rendered messages sent to the model provider.
• Provider, endpoint, model and generation parameters.
• Raw model response and any post-processing.
• Tool calls, arguments, results and errors.
• Reviewer scores, comments, approvals and rejections.
• Token usage, costs, duration, retries and caching.
• Data-disclosure classification and destination.

18.2 Explainable orchestration

When the Orchestration Actor creates a new team, assigns an expensive model or changes a workflow, it should record the reason. The goal is not a perfect explanation of hidden model reasoning. It is an operational explanation of the decision, evidence, policy and alternative considered.

19. Example Applications

19.1 Software delivery

A software team can divide work among product, analysis, architecture, frontend, API, database, infrastructure, testing, security and review Actors. Human Actors define value, test usability and approve release. This is the clearest initial application because code, tests and repository events provide strong evidence for automated oversight.

19.2 Community and volunteer organisations

A community group could create Actors for grant research, budgeting, policy review, volunteer coordination, event planning and communications. Human committee members remain the decision-makers, while AI Actors perform research, drafting and administration. The organisation retains its documents, memory and processes locally or in its own cloud account.

19.3 Small business operations

A small business could assemble a team for customer research, workflow design, proposal preparation, bookkeeping assistance, documentation and compliance review. Different models can be selected according to cost and sensitivity, while Human Actors approve financial, legal and customer-facing decisions.

19.4 Individual research and creation

An individual might use Research, Evidence Review, Writing, Project Planning and Personal Knowledge Actors. Sensitive work can remain local, while public research tasks use external models. The same workflow principles provide critique, source checking and cost control.

20. Consulting and Service Model

A fully open-source platform can support a strong consulting model because the primary value lies in designing and improving the client’s Actor team, not in withholding the engine. A consultant could help a client understand its work, select deployment options, define personas, connect knowledge, establish governance and measure results.

20.1 Possible services

• Discovery and process mapping.
• Local, private-cloud or client-cloud deployment.
• Actor-team design and persona engineering.
• Model evaluation and routing strategy.
• Knowledge-base and memory integration.
• Security, privacy and approval policies.
• Workflow, Kanban and system integration.
• Training for Human Actors and administrators.
• Evaluation, optimisation and ongoing support.

20.2 Client proposition

Plain-language proposition Imagine having ten people dedicated to different parts of your work: a researcher, analyst, project manager, specialist builders, reviewers and a cost controller. This system helps you create the AI version of that team, while keeping people involved wherever judgement and approval matter.

20.3 Ownership

The client should own or control its project data, Actor definitions, prompts, memories, workflows and artefacts. The consultant is paid for expertise, implementation and improvement rather than for creating a permanent dependency. Some deployments may be mostly local; others may be largely cloud-based in the client’s own account. The governing principle is control and portability, not a single deployment ideology.

21. Consolidated Functional Requirements

FR-001 ** MUST**

Actor registry. The system shall create, version, clone, archive and restore AI and Human Actor profiles.

FR-002 ** MUST**

AI Actor persona. An AI Actor shall define role, goals, responsibilities, exclusions, system instructions, model, tools, memory, permissions, budget and escalation rules.

FR-003 ** MUST**

Human Actor participation. A Human Actor shall be assignable to tasks, reviews, approvals, tests and decisions within the same workflow.

FR-004 ** MUST**

Dynamic team creation. The Orchestration Actor shall be able to recommend, create or select Actors required for a project, subject to policy and human governance.

FR-005 ** MUST**

Work decomposition. The system shall decompose outcomes into capabilities, stories, tasks, dependencies, acceptance criteria and review points.

FR-006 ** MUST**

Scope boundaries. Actor profiles shall state excluded work and consultation rules for crossing responsibility boundaries.

FR-007 ** MUST**

Structured handovers. The system shall record sender, recipient, context, artefacts, request, constraints and expected response for Actor handovers.

FR-008 ** MUST**

Multi-model routing. Different Actors and tasks shall be able to use different local or cloud model endpoints.

FR-009 ** MUST**

Local-only mode. The system shall operate with external model access disabled.

FR-010 ** MUST**

Durable workflows. Workflows shall pause, checkpoint, survive restart and resume without losing completed state.

FR-011 ** MUST**

Workflow patterns. The engine shall support sequence, parallel work, branching, loops, retries, escalation, sub-workflows and approvals.

FR-012 ** MUST**

Scheduled oversight. The system shall run Actor tasks on schedules and in response to project events.

FR-013 ** MUST**

Intervention. Authorised oversight Actors shall flag, pause, redirect or stop work according to policy.

FR-014 ** MUST**

Critique loop. Reviewers shall approve, reject, request revision, request clarification or escalate work.

FR-015 ** MUST**

Loop limits. Every iterative loop shall support iteration, time and cost stop conditions.

FR-016 ** MUST**

Project memory. The system shall store local project facts, decisions, artefacts and accepted outcomes.

FR-017 ** SHOULD**

Role memory. The system shall maintain versioned reusable memory for Actor roles, with controlled promotion from project experience.

FR-018 ** MUST**

Memory permissions. Memory access shall be controlled by Actor, project and sensitivity.

FR-019 ** MUST**

Prompt transparency. Users shall inspect the stored prompts and final rendered model request.

FR-020 ** MUST**

Trace capture. The system shall record model, parameters, responses, tools, errors, approvals, costs and disclosure decisions.

FR-021 ** MUST**

Data classification. Projects and artefacts shall support sensitivity classification and external-disclosure policy.

FR-022 ** MUST**

Context minimisation. The system shall send external providers only the context required for the assigned task.

FR-023 ** SHOULD**

Task board. The system shall provide projects, stories, tasks, status, ownership, dependencies and acceptance criteria.

FR-024 ** MUST**

Cost control. Budgets shall be configurable by project, Actor, workflow and task.

FR-025 ** MUST**

Cost reporting. The system shall report tokens, provider costs, local inference time, retries and cost per accepted task.

FR-026 ** MUST**

Permission control. Actor permissions shall separately govern files, tools, network, secrets, databases, Git and deployment.

FR-027 ** SHOULD**

Isolated execution. High-risk tools and coding work shall be executable in isolated environments.

FR-028 ** MUST**

Artefact management. The system shall retain and link code, documents, tests, reviews and releases to tasks and runs.

FR-029 ** MUST**

Export and backup. Users shall export Actor profiles, workflows, memories, traces and project history in documented formats.

FR-030 ** MUST**

Open local control plane. All essential orchestration, governance and observability functions shall run without a proprietary hosted control plane.

22. Non-Functional Requirements

ID	** Requirement**	** Target or interpretation**
NFR-001	Local deployability	Installable on a capable workstation or server using documented open-source components.
NFR-002	Portability	Core data and configuration can be moved between environments and providers.
NFR-003	Reliability	A process restart does not silently lose accepted work or workflow state.
NFR-004	Auditability	Every material action is attributable to an Actor, model, tool, workflow and approval state.
NFR-005	Security	Least privilege, isolation, secret protection and explicit high-risk approvals.
NFR-006	Usability	A knowledgeable user can inspect the team, workflow, current tasks, costs and reasons for pauses.
NFR-007	Extensibility	New model providers, tools, Actor types and workflow nodes can be added through documented interfaces.
NFR-008	Performance	Routine control-plane operations remain responsive while long-running work executes asynchronously.
NFR-009	Scalability	Supports a single user locally and can expand to a small organisational deployment.
NFR-010	Accessibility	The management interface should support keyboard use, readable contrast and understandable status information.
NFR-011	Open-source integrity	No indispensable feature is disabled without a commercial subscription.
NFR-012	Reproducibility	A completed run can be reconstructed from its Actor, workflow, prompt, model and artefact versions where providers permit.

23. Suggested Minimum Viable Platform

The first useful version should prove the coordination model before attempting a completely autonomous organisation. It should focus on one strong use case, preferably software delivery, and support a limited but complete team.

23.1 MVP scope

• Local Docker-based deployment.
• PostgreSQL or another open database for project and workflow state.
• AI and Human Actor profiles with roles, prompts, models, tools and boundaries.
• A visual or YAML workflow supporting sequence, review loops, pause and human approval.
• Connection to at least one local OpenAI-compatible endpoint and two optional cloud providers.
• A project board with tasks, ownership, status and acceptance criteria.
• A local Git repository and isolated coding workspace.
• Prompt, response, tool and cost traces stored locally.
• Architecture, testing and cost watchdogs.
• Export of the full project, team and workflow configuration.

23.2 Initial demonstration team

Actor	** Primary responsibility**	** Suggested execution**
Product Owner	Outcome, value, scope and acceptance.	Human Actor supported by an AI Product Analyst.
Business Analyst	Research and structured requirements.	Local or lower-cost hosted model with web tools.
Architect	System boundaries, interfaces and technical decisions.	Stronger reasoning model.
JavaScript Developer	Frontend and JavaScript implementation.	Local coding model.
Database Developer	Schema, migrations and data access.	SQL-capable local model.
Infrastructure Engineer	Docker, local services and deployment configuration.	Local coding model with restricted tools.
Tester	Automated tests and defect evidence.	Local model plus deterministic test runner.
Reviewer	Independent code and design critique.	Different model family from developer.
Cost Controller	Budget, token and efficiency monitoring.	Small local model plus calculations.
Human Tester	Usability and real-world acceptance.	Human Actor.

24. Measures of Success

1. A broad project can be converted into a coherent team and work plan without immediately generating implementation.

2. Specialised Actors complete bounded work and consult others before changing external domains.

3. Different Actors successfully use different local and cloud models in one project.

4. Reviewer Actors identify genuine defects and return work for correction.

5. Oversight Actors detect architecture, scope or cost drift during a long-running project.

6. Human Actors can perform tests, supply decisions and approve progression within the workflow.

7. A workflow can stop, restart and resume without losing accepted work.

8. The system records exactly which prompts, models, tools and artefacts produced an outcome.

9. The project remains usable when cloud providers are disabled or replaced.

10. Model expenditure is lower or more predictable than an equivalent single-frontier-model workflow.

11. Actor personas demonstrably improve across evaluated versions.

12. Another person or organisation can deploy and own the system without dependence on a proprietary control plane.

Appendix A. Example Actor Profiles

A.1 JavaScript Developer Actor

Field	** Example definition**
Role	JavaScript and frontend implementation specialist.
Goal	Deliver maintainable, accessible frontend features that conform to approved interfaces.
Responsibilities	Components, client state, validation, accessibility, frontend tests and documentation.
Exclusions	Do not independently redesign the database, API contract, deployment architecture or authentication policy.
Consultation	Raise a structured change request to the API, Database, Infrastructure or Architect Actor when an external change appears necessary.
Model	Local coding model selected for JavaScript and repository work.
Tools	Read/write assigned frontend paths, run frontend tests and linting, read approved API specifications.
Memory	Project frontend decisions, design conventions, accepted patterns and relevant role memory.
Review	Code Reviewer, Tester and Human UX Tester.
Budget	Task token limit, maximum revision cycles and escalation to stronger model after repeated failure.

A.2 Architecture Watchdog Actor

Field	** Example definition**
Role	Read-only architecture conformance monitor.
Goal	Detect structural drift before it spreads across the project.
Inputs	Approved architecture, decision records, repository changes, dependency graph and active tasks.
Checks	Layer violations, duplicated services, unauthorised dependencies, interface divergence and misplaced logic.
Authority	Flag issues, open review tasks and pause affected work when severity exceeds policy threshold.
Limitations	Does not directly rewrite implementation code.
Schedule	After defined commits, completed stories or elapsed intervals.
Escalation	Architect Actor, then Human Technical Approver for unresolved high-impact issues.

A.3 Human Product Owner Actor

Field	** Example definition**
Role	Human owner of value, priorities and acceptance.
Responsibilities	Clarify users, approve scope, make trade-offs, test important outcomes and accept or reject releases.
Authority	May change priority, approve budget exceptions and stop work that no longer creates value.
Notifications	Receives concise decision requests with evidence, options, cost and consequences.
Availability	Workflow should plan around declared availability and must not infer approval from silence.
Record	Decisions and feedback are stored with the same project history as AI Actor work.

Appendix B. Example Software Delivery Workflow

The following illustrates how Actor creation, specialised work, oversight and human participation can combine in one durable workflow.

1. Project initiation. A Human Product Owner provides the problem, intended users, constraints, budget and desired timeframe.

2. Team proposal. The Orchestration Actor recommends the required AI and Human Actors, models, permissions and review pattern.

3. Human approval. The Product Owner approves or modifies the team, budget and data policy.

4. Discovery. The Business Analyst researches the domain and creates requirements with assumptions and evidence.

5. Product definition. The Product Owner and Product Analyst set priorities and acceptance criteria.

6. Architecture. The Architect defines components, interfaces, security boundaries and deployment approach.

7. Work decomposition. The Scrum Master Actor creates stories, tasks, dependencies and review stages.

8. Specialist delivery. JavaScript, API, Database and Infrastructure Actors work on bounded tasks, often in parallel.

9. Continuous checks. Tests run automatically while Architecture, Scope, Security and Cost Watchdogs inspect progress.

10. Structured consultation. An Actor that requires another domain to change submits a change request rather than modifying it silently.

11. Critique loops. Reviewers return defects to the responsible Actor until criteria are met or escalation is triggered.

12. Human experience test. A Human Tester tries the system and records whether the experience is understandable and useful.

13. Integration review. The Integration Reviewer checks that accepted modules operate together and that project memory reflects the final design.

14. Release decision. The Human Product Owner and Technical Approver review evidence, residual risks and costs before release.

15. Learning review. The system proposes improvements to Actor personas and workflows; authorised humans approve promotion into reusable memory.

Core loop Plan → Assign → Build → Observe → Test → Critique → Correct → Human validation → Integrate → Release → Learn

Appendix C. Open-Source Project Evaluation Checklist

Any candidate codebase should be tested against the following questions rather than judged only from screenshots or repository descriptions.

Area	** Evaluation question**
Licence	Is the complete platform under an OSI-recognised or otherwise genuinely open-source licence?
Control plane	Can workflows, schedules, approvals, traces and memory operate without a proprietary hosted service?
Local deployment	Can the documented system be installed on a workstation or private server?
Actor profiles	Can roles, prompts, tools, models, memories, permissions and exclusions be represented cleanly?
Human Actors	Can people own tasks, submit work, test, approve and make decisions inside the workflow?
Multiple models	Can different Actors use different local and cloud endpoints in the same project?
Prompt visibility	Can the user inspect the final rendered provider request, not only an editable prompt field?
Durability	Can long workflows pause, restart and resume from checkpoints?
Critique loops	Can work be returned, corrected, retested and escalated with limits?
Scheduling	Can oversight tasks run periodically and in response to events?
Intervention	Can an authorised Actor pause or redirect active work?
Work management	Are tasks, dependencies, acceptance criteria, status and ownership visible?
Memory	Are project and role memories local, permissioned and exportable?
Security	Can tool, network, file, secret and deployment permissions be constrained?
Costs	Are tokens, provider cost, local compute and retries recorded?
Portability	Can Actor profiles, workflows and project history be exported in documented formats?
Extensibility	Can new providers, tools, Actors and workflow nodes be added without modifying a closed service?
Community and maintenance	Is the project actively maintained, documented and sufficiently stable for the intended use?

Closing Statement

The central proposition is that AI becomes more useful when it is organised into accountable roles. A trusted local orchestration platform can combine specialised models, strong prompts, bounded authority, repeated review and human judgement into a team that is more capable than any one model acting alone.

This approach can reduce cost, make practical use of local hardware, preserve organisational knowledge and help individuals or groups gain access to structured expertise. The open-source requirement ensures that the value remains in the people, personas, workflows and knowledge created around the system, rather than being captured by a proprietary control plane.