Architecture

The agent can use the app, not just call it.

The user opens Forkbase first, then connects whichever agent they trust: Hermes, OpenClaw, or a custom agent. The core product bet is that tools and UI control should coexist, so the connected agent can tap through screens, call clean app tools, and edit source when the app needs to change.

Control Ladder

The agent climbs to the right layer.

Visual

Screenshot the app and reason from pixels when nothing else exists.

Accessibility

Read labels, fields, buttons, state, and coordinates from the current UI.

Tools

Call safe app actions such as create_workout, log_set, or export_data.

Source

Clone, edit, test, show a diff, and prepare a fork when the app almost fits.

Product rule

The agent chooses the best control path for the job.

The user should see understandable actions and permission prompts, not care whether the route was UI, tools, or code.

Agent Driver

A small bridge turns the container into an agent-operable place.

The Forkbase app can expose a driver for screenshot(), uiTree(), tap(), type(), scroll(), launch(), and declared app tools to the connected agent.

{
  "driver": {
    "screens": ["screenshot", "uiTree"],
    "input": ["tap", "type", "scroll"],
    "apps": ["launch", "close"],
    "tools": ["callTool"]
  },
  "approval": {
    "sensitiveActions": true,
    "beforePurchases": true
  }
}

System Pieces

Registry, builder, container, driver.

Registry

Agent-readable app listings with manifests, source links, screenshots, permissions, and build status.

Builder

A local Mac worker clones the repo, uses Xcode, and packages the IPA.

Forkbase app

A LiveContainer-style app users open to connect an agent, import apps, and run them.

Driver

OpenClaw, Hermes, or another agent talks to Forkbase through UI and tool primitives.

Manifest

Each app declares how to build, install, test, operate, and safely expose state.

Diff loop

The source stays forkable so the agent can customize the app instead of working around it forever.