PAIA. A private AI operating environment for serious work.

Instead of treating artificial intelligence as a temporary conversation inside a browser tab, PAIA treats it as a persistent working environment: a companion with long-term continuity, a collection of specialised task agents, a secure tool-execution layer, and an integrated development workspace where models can inspect, modify, test, and review real software projects.

The ambition is to create a personal AI system that can remain useful over years, not merely answer isolated prompts. It should understand ongoing projects, preserve important context, coordinate specialised agents, operate tools under explicit permission, and help transform unfinished ideas into working software.

More than a chat interface

Most AI products begin and end with a message box. PAIA uses conversation as one interface, but the underlying system is closer to an agent harness and personal development environment.

A conversation can be connected to persistent memory, project context, model profiles, approved tools, and an auditable execution history. The model is not expected to hold the entire system together through prompting alone. PAIA provides the surrounding infrastructure required to make an AI agent reliable enough for real work. That infrastructure includes:

• Persistent conversations and structured context
• Scoped long-term memory
• Specialised Companion, Coder, Researcher, and Reviewer roles
• Per-project repository access
• Controlled tool and command execution
• An integrated File Studio powered by Monaco
• File history, diffs, rollback, and roll-forward workflows
• Local and opt-in cloud model profiles
• Credential isolation and cloud spending controls
• Visible approvals, diagnostics, and execution records

The goal is not to give a model unrestricted access to a computer. The goal is to build a carefully controlled environment in which capable models can do meaningful work without hiding what they are doing.

A harness for local coding models

One of PAIA's central goals is to become a strong coding harness for local models.

Local models have improved rapidly, but running a model is only one part of building an effective coding agent. The model also needs project context, file discovery, editing tools, terminal access, execution feedback, change tracking, recovery mechanisms, and clear boundaries around what it may touch. PAIA provides that surrounding system.

A coding agent can be linked to an explicitly authorised project and given a focused task. It can inspect the project structure, read relevant files, propose changes, execute approved commands inside a controlled sandbox, and review the resulting output. The owner remains able to inspect the same files, terminal output, revisions, and diffs through the File Studio interface.

This makes the model only one replaceable component in a larger engineering loop:

The harness is designed to support different models without rebuilding the workflow around each provider. A small local model may handle routine classification or formatting. A stronger coding model may work on implementation. A separate reviewer can inspect the resulting diff. Models can evolve while the surrounding project, permission, and audit infrastructure remains stable.

The long-term aim is to make local coding agents feel less like autocomplete and more like junior engineering collaborators operating inside a disciplined development process.

File Studio: an IDE built for human-agent collaboration

PAIA includes an integrated File Studio for working with projects that have been imported into a PAIA-owned workspace. It is not intended to replace every feature of a conventional IDE, but is designed around the specific interaction between an owner and one or more AI agents. It combines:

• A searchable, keyboard-accessible project explorer
• Monaco-based source editing and syntax highlighting
• Word wrapping and editor state persistence
• Resizable explorer, editor, history, and terminal panes
• Per-project layout restoration
• File metadata, language, size, and dirty-state indicators
• Integrated sandbox terminal output
• Revision history and file restoration
• Diff inspection and change-batch review
• Rollback and roll-forward preparation
• Automatic synchronisation when agents change project files

When an agent works on a task, the owner should be able to watch the same project evolve without manually reopening files or wondering whether the interface is showing an outdated copy. File Studio is therefore being built as a live surface over the agent workspace, not as a detached text editor: a shared technical environment where the agent operates through structured tools, while the owner can inspect and intervene through a familiar IDE-like interface.

Local-first by default

PAIA is designed to work with local inference through Ollama and OpenAI-compatible local model servers.

Local execution matters for more than offline access. It changes the relationship between the owner and the system. Conversations, project files, and personal memories do not need to leave the machine merely because an AI feature is being used. Models can be replaced, upgraded, or specialised without surrendering the surrounding application state.

Local models remain the default, but PAIA can also support selected cloud providers through explicit model profiles. Cloud access is opt-in rather than silently selected. Credentials are sealed using the operating system's keyring and are never stored as plain text in PAIA's database.

Cloud execution also passes through local safeguards, including provider verification, model pricing metadata, concurrency controls, and an owner-configurable monthly spending ceiling. If a cloud model cannot be priced safely, PAIA is designed to fail closed rather than create an unknown bill. The intention is not to reject cloud intelligence. It is to make cloud access deliberate, visible, and replaceable.

Persistent memory without surrendering control

A genuinely personal AI needs continuity. It should not require its owner to repeat the same preferences, identity details, project background, and corrections in every conversation.

At the same time, autonomous memory is dangerous when implemented as "save whatever the model thinks is important." Models can misunderstand context, preserve temporary statements as permanent facts, or accidentally treat instructions and sensitive information as memories.

PAIA approaches memory as a validated subsystem. Memories are structured, typed, and scoped. Companion memories remain separate from project and task-agent context. Explicit owner commands can save important facts directly, while bounded automatic extraction can be enabled for high-confidence information. Ambiguous content fails closed, duplicates are avoided, and secret-like information is rejected because the memory system is not intended to become a credential vault.

The long-term goal is a memory system that is useful enough to create continuity while remaining inspectable, editable, and reversible. The owner should always be able to understand what PAIA remembers, where it applies, and why it was saved.

The Companion and task agents are deliberately different

PAIA separates two kinds of intelligence that are often blended together.

The Companion is personal. It maintains conversational continuity, recalls owner-approved memories, and develops a consistent relationship with one person over time.

The task agents are tools. A Coder should be precise, technical, and focused on implementation. A Researcher should gather and evaluate information. A Reviewer should challenge assumptions and inspect work critically. These agents should not inherit private companion context unless that information is explicitly relevant and authorised.

This boundary is important. A coding tool does not need access to every personal memory, and a personal companion should not silently gain unrestricted access to every repository. PAIA therefore treats identity, memory, project access, tool permissions, and model selection as separate layers. Agents receive explicit project links and capabilities according to the work they are expected to perform.

Controlled execution instead of unrestricted autonomy

An AI that can edit files and execute commands is useful. An AI that can do so invisibly and without limits is a security problem. PAIA's execution model is designed around visible authority.

Project access is explicit. Commands requiring execution pass through an approval system. Tool runs are recorded. Repository changes can be grouped into reviewable batches. Code execution remains inside a Docker-based sandbox boundary rather than silently falling back to unrestricted host execution.

This creates a separation between reasoning and authority:

1. 1

   A model may propose an action.

2. 2

   PAIA determines whether that action is allowed.

3. 3

   The owner approves sensitive operations.

4. 4

   The tool layer performs the action.

5. 5

   The result is recorded and returned to the model.

6. 6

   Changes remain available for human inspection.

The model is never treated as the security boundary. Its output is untrusted input to a system that validates scope, permissions, and data before acting.

Model orchestration without provider lock-in

Different tasks benefit from different models. PAIA is being built around model profiles rather than one permanently embedded provider.

A profile can define the provider, endpoint, model, generation settings, and intended role. The Companion can use one model while coding or review tasks use another. Local models can handle private or routine work, while an explicitly configured cloud model can be selected for tasks that require greater capability.

Tool schemas are attached through a provider-independent interface, allowing the agent layer to work across supported model backends without duplicating the entire application for each vendor. Over time, PAIA is intended to make model selection increasingly practical: choosing models based on privacy requirements, capability, latency, cost, context size, and the type of work being performed.

The intelligence is modular. The environment, memory, permissions, and project history belong to the owner.

Built for inspectability

Agent systems can fail in subtle ways. They may use stale files, lose tool output, repeat failed actions, misunderstand a project boundary, or produce a plausible answer without completing the underlying task. PAIA is designed to make those failures visible.

Conversations retain diagnostics. Tool calls and approvals are auditable. File changes appear in revision history. Terminal output remains available while the workspace layout changes. Model profiles can be tested before use. Memory can be inspected and corrected. Project permissions are visible instead of being hidden inside prompts.

The owner should not have to infer whether an agent completed a task from the confidence of its final message. The surrounding system should provide evidence. This principle also shapes PAIA's development process: features are treated as complete only after focused tests, full automated suites, production builds, and, where appropriate, live verification against the packaged desktop application.

The long-term goal

PAIA is an attempt to build a durable interface between a person, their models, and their digital work. The long-term vision is a system capable of:

• Maintaining useful personal continuity over years
• Coordinating multiple specialised agents
• Running primarily on owner-controlled local infrastructure
• Understanding and maintaining substantial software projects
• Selecting appropriate models for different kinds of work
• Recovering from partial failures without losing progress
• Explaining which memories, files, and tools influenced an answer
• Preparing work autonomously while keeping consequential actions approval-gated
• Preserving a complete and inspectable history of important changes
• Remaining useful as individual model providers come and go

The goal is not unlimited autonomy. It is dependable autonomy: a system that can move work forward on its own where the boundaries are clear, stop when authority is missing, and leave behind enough evidence for the owner to understand exactly what happened.

A personal AI workshop

PAIA sits somewhere between a private assistant, an agent runtime, a coding IDE, and a personal operating environment. It is a place where conversations can become plans, plans can become project tasks, agents can turn those tasks into reviewed changes, and useful knowledge can persist beyond the current session.

It is being built for the idea that the future of personal AI will not be one enormous model living behind a chat box. It will be a system of models, memories, permissions, tools, and interfaces working together under the control of the person who owns them.

PAIA is still in active development.

But the direction is clear: build an AI environment that is private enough for personal context, controlled enough for real system access, and capable enough to help create serious software.

What's underway

One upcoming direction is bringing all the "skills" (capabilities and tools) already spread across PAIA, Codex, Claude, and other local AI tools into one place: discover them, browse them, configure them, and turn them on or off per agent or project. The first phase is deliberately read-only: discovery and normalised manifests, without scanning arbitrary disks or modifying other installations.