Skip to content
ZJ

Case study /02 · Concept · in development

Phandor

AI Automation · Productivity

An intelligent desktop automation concept designed to help users complete repetitive digital workflows.

Phandor explores a specific bet: most repetitive desktop work follows patterns an AI agent can learn and execute — if, and only if, the human approval model is designed as carefully as the automation itself.

  • AI agents
  • Desktop automation
  • Workflow engines
  • Context models
  • Approval systems
Phandor end-to-end workflow flow: a user request moves through the perception layer, context model and planner to a human approval checkpoint before the execution engine runs the approved step, with every stage writing to an audit trail.

Context

Knowledge workers lose hours to workflows that are too irregular for classic macros but too repetitive for humans: filing, transferring, reformatting, cross-checking. Agentic AI can bridge that gap, but trust is the actual product.

Problem

Naive desktop agents fail in two directions — too timid to be useful, or too autonomous to be safe. Phandor's design problem is the boundary: what the agent does freely, what it proposes, and what it must never touch.

Constraints

  • Every irreversible action requires explicit human approval — no exceptions by design.
  • The agent's context understanding must be inspectable: users see what it thinks it is doing.
  • Workflows must be interruptible and resumable at any step.
  • Safety boundaries are enforced by the execution engine, not by prompt instructions.

Responsibilities

  • Agent architecture: perception, planning and execution separation.
  • Workflow execution engine with step-level checkpoints.
  • Human approval interaction model and its interface.
  • Safety boundary system defining allowed, propose-only and forbidden action classes.
  • Context understanding across applications and documents.

Architecture

  • A perception layer builds a structured model of screen and application state; the planner reasons over that model, never over raw pixels alone.
  • Plans compile into explicit step sequences; each step declares its action class before execution.
  • The execution engine enforces action-class policy mechanically — forbidden classes cannot execute regardless of what the model outputs.
  • Approval checkpoints render the pending action, its target and its consequence in plain language.

Key decisions

  • Policy in the engine, not the prompt: safety that depends on model obedience is not safety.
  • Plans are shown before they run — users approve intent, then supervise execution.
  • Prefer many small approvals early, earning batch approvals as trust in a workflow accumulates.
  • Every action is logged with its plan step, so a workflow is auditable after the fact.

Implementation

  • Workflow definitions capture recurring tasks as parameterized plans the agent adapts per run.
  • The approval UI is optimized for glance-speed decisions: action, target, consequence, approve/reject.
  • Interruption is first-class — pausing mid-workflow leaves a resumable, inspectable state.
  • Context models persist per workflow, improving step reliability run over run.

Performance

  • Perception favors structured accessibility data over vision where available — faster and more reliable.
  • Plan compilation front-loads reasoning so execution steps stay fast and deterministic.

Outcomes

  • A working concept demonstrating supervised end-to-end workflow execution.
  • The action-class safety model held up against adversarial prompt testing in development.
  • [PLACEHOLDER — replace with pilot results when the concept reaches user testing.]

Lessons

  • In agentic products, the approval interaction is the product — automation is the implementation detail.
  • Mechanical enforcement beats behavioral alignment for hard safety boundaries.
  • Users trust agents whose reasoning they can inspect, interrupt and override.

Software Architecture

Six-stage flow diagram. 1. User request: define a goal or select a workflow, via natural language, workflow template or parameters and config. 2. Perception layer: read screen, apps and documents, accessibility-first, capturing UI and app state. 3. Context model: build structured workflow state from apps, docs, fields and intent. 4. Planner: create an explicit step sequence through goal decomposition, step sequencing and action classes. 5. Human approval checkpoint: show action, target and consequence, with approve or reject, edit or reorder, and batch approval as trust grows. 6. Execution engine: run the approved step only — interruptible, resumable and audit logged. Every stage writes to an audit trail and workflow memory that logs each step, keeps resumable state and improves reliability over time, then the flow loops back for the next approved step. Irreversible actions always require explicit approval, because trust comes from inspectable approval.
Architecture diagram in three columns. Left, input sources: desktop and apps, files and documents, web and APIs, user instructions. Centre, the core agent engine as a top-down stack: perception layer using structured accessibility data first, context model of applications, documents, fields and workflow state, planner producing an explicit parameterized plan, action classifier splitting actions into allowed, propose-only and forbidden, and a deterministic, interruptible, resumable execution engine. Right, the control layer exchanging with that engine: a policy enforcer that blocks forbidden actions mechanically, an approval UI showing action, target and consequence, and a state manager for pause, resume and rollback. Both feed an outputs and learning band of approved actions, audit logs, workflow templates and reliability improvements. Four properties are called out: inspectable intent, mechanical safety, step checkpoints and interruptible execution.