Skip to content
optophi.
Try the demoTry the demo
OPTOPHI · THE DEPLOYMENT VISION

Give your agents
a place to run.

Define, deploy and operate agents with controlled environments and evidence. Bring agent configuration and the infrastructure needed to host it into one reviewable operating contract: where models run, where company knowledge and memory are stored, and who can use them.

Our ambition for PyGubernator is a Kubernetes-inspired control plane for agents: declare how they should run, inspect their state, and reconcile deployments on infrastructure you control.

Explore local deployment Explore cloud deployment
Target architecture · A deployment manifest and reconciliation are proposed
Your versioned agent intentBehavior · capabilities · boundaries
Local target settingsCloud target settings

Target experience: shared intent, explicit environment bindings. Moving files, memory or browser sessions requires its own state-transfer plan.

LOCAL DEPLOYMENT · TARGET EXPERIENCE

Run locally.
Stay in control.

Turn your own machine into a home for your agents. Choose a model endpoint, connect approved tools, and keep workspace and storage choices explicit.

  1. Bootstrap the local runtime.A simple setup reusing the existing runtime and Compose.
  2. Apply your agent setup.Bind the revision, model, tools and storage to this machine.
  3. Start a conversation. Get to work.Use the local interface and return to retained work.

The host must be running and reachable for the agent to work. Local execution can use an approved local or remote model endpoint; the binding determines where inference happens.

Explore today’s local source preview
YOUR MACHINE · CONCEPTUAL TARGET
You and your agentLocal chat / work interface
PyGubernatorLocal control service + workers
Your model bindingApproved endpoint
Your retained stateWorkspace + memory
Your capabilitiesTools + limits
Available while your host is running
CLOUD DEPLOYMENT · TARGET EXPERIENCE

Run in the cloud.
Keep your agents within reach.

Close your laptop. Come back to your agent from another device. A persistent runtime on approved infrastructure can give your team a shared place to work with company-owned agents.

  1. Choose a configured destination.Your organization prepares the compute, network and access controls.
  2. Deploy the approved agent to your environment.Bind workers, model endpoints, state, permissions and limits.
  3. Connect securely from your devices or team.Use authenticated access to the same retained agent workspace.

Reachability depends on the host, network and operating setup. Hosting, capacity and model usage have their own costs. A private cloud runtime can use separately approved model endpoints.

Discuss the cloud roadmap
YOUR CONFIGURED CLOUD · CONCEPTUAL TARGET
Your laptop
Your devices
Your team
Authenticated access
Persistent agent runtimePyGubernator control service + workers
Retained workConfigured storage
Approved modelsExplicit endpoints
Bounded actionsTools + permissions
Runs independently of your laptop
THREE LAYERS. ONE OPERATING CONTRACT.

From your terminal to running work.

A CLI expresses intent. A durable service manages the lifecycle. Configured execution infrastructure hosts the work.

What is available today
  1. 01

    The CLI

    The target is a kubectl-like interface for validating desired configuration, reviewing changes, applying deployments and inspecting state. Today’s source CLI supports the documented local configuration and chat path.

  2. 02

    The durable control service and runtime

    Build on durable workers, agent lifecycle and stored work. The proposed deployment service would retain desired and observed state, coordinate permitted transitions and expose progress, failures and recovery evidence.

  3. 03

    The infrastructure behind the agent

    Workers, storage and memory, approved model endpoints, secret references, and isolated execution where needed. The planned simple local bootstrap should reuse the existing runtime and Compose; later adapters should target remote environments you have configured.

PROPOSED DEPLOYMENT BINDINGS

Specify the agent.
Bind its environment.

The target deployment manifest would connect an agent revision to the environment, capabilities, state and limits it needs. Changes should be versioned, reviewed and traceable to what runs.

These are conceptual responsibilities. A unified manifest schema and deployment reconciliation are proposed, not released.

Agent revision
The versioned behavior you intend to run.
Execution target
An explicit reference to a prepared destination registered by the operator.
Workspace and browser state
Optional persistent sessions with explicit ownership and cleanup; planned for computer use.
Scoped memory
The permitted knowledge and retained state for this deployment.
Tools and permissions
Named capabilities, host grants and secret references, with bounded external actions.
Operating limits
Resource, concurrency and usage boundaries that can be checked and observed.
BUILD ON VERIFIED FOUNDATIONS

A practical path from local to operated.

AVAILABLE TODAY · CURRENT SOURCE

Run within a configured environment.

Agent manifests, local runtime startup and stored conversations provide a starting point. Durable workers, lifecycle primitives, logical provisioning plans and host-authorized placement support deeper host integrations.

A placement plan checks configured capabilities and grants. The host supplies compute, credentials, isolation and capacity. Identity/access, network controls, retention and audit also belong to the configured deployment. Selected profiles still need operational qualification.

Check source-preview availability
TARGET STATE · PROPOSED & PLANNED

Reconcile intent with running state.

The first planned service runs on one prepared company-controlled target. A durable service would observe its state and drive authorized changes and recovery, preserving evidence and surfacing uncertain external outcomes before retry.

A streamlined local bootstrap and adapters for prepared remote targets are future work. Persistent computer sessions, browser profiles and human takeover are optional planned capabilities.

Infrastructure you control, with explicit support boundaries.

Universal cloud provisioning and an implemented Kubernetes operator are outside today’s capabilities. Computer sessions require a supported execution profile; creating an agent does not allocate a dedicated computer.

START WITH THE WORK YOU WANT TO RUN

Your agents. Your infrastructure.

Explore PyGubernator or discuss the deployment profile your work needs.

Explore PyGubernator Discuss your deployment
Feedback