← Back to selected work

PRODUCT CASE

Agent Computer

An open-source workspace that turns invisible agent work into apps, files, projects, state, handoffs, and review points people can inspect and control.

  • Role: product concept, system design, implementation, documentation, and public operation
  • Status: open source and used for real work
  • Scope: agent apps, file-based state, handoffs, approvals, QA, and tools

Inspect now

Agent Computer structure: source material passes through agent apps into inspectable project files
Agent work made visible through apps, files, and projects

Why This Workspace Needed to Exist

Delegating in natural language became easier. As the work grew longer, answering basic questions became harder:

  • What is the agent doing now?
  • What is complete and what remains?
  • Did the original intent survive into the next step?
  • Where should the workflow stop when a result is weak?
  • Where do decisions and outputs live after the conversation ends?

People already understand computers through apps, files, projects, and state. I designed Agent Computer around that familiar structure instead of inventing a new agent-control language.

Treat Agents as Apps and Work as Files

Researchers, document converters, report writers, and presentation builders are installed as problem-specific apps. Each app has an input contract, tools, workflow, output location, and review criteria.

Outputs are not only chat messages. Intermediate decisions, data, reports, and QA logs live inside a project. The next app reads a durable handoff rather than relying on a compressed recollection of the conversation.

Basic Flow

Natural-language request
→ choose the right agent app
→ confirm input and work contract
→ save intermediate evidence and decisions
→ hand off state and limitations
→ human approval or QA
→ preserve the result and verification record

Responsibility Split

OwnerResponsibility
Agent appProblem-specific role, input, tools, workflow, and output contract
Project filesPreserve intermediate decisions, state, artifacts, limits, and next actions
ModelInterpret, analyze, and generate inside each app
QA rules and toolsCheck format, evidence, completion conditions, and failure locations
PersonAnswer direction-changing questions, approve external actions, and make final judgments

Problems Solved While Building

Visual Document Ingestion: Recover Relationships Lost by Flat Text Extraction

  • Observed problem: PDF extraction flattened panels, arrows, captions, and hierarchy into one sequence of text.
  • Reasoning: A fast map for understanding and the original page for exact verification should be separate but connected.
  • Implementation: Page text, document map, and page renders were preserved as three layers with links between them.
  • What changed: An agent could understand the reading order while returning to the source for exact wording and visual relationships.

Durable Handoff: Separate “Generated” From “Ready for the Next Step”

  • Observed problem: The existence of a file did not reveal remaining review, next actions, or boundaries that had to be preserved.
  • Reasoning: Completion, incomplete work, next action, and limitations needed to exist outside chat.
  • Implementation: Checkpoints and handoff files record state for the next app or person.
  • What changed: Interrupted and multi-role work could be resumed by reading the project rather than reconstructing the conversation.

QA Before Composition: Stop Fluent but Weak Claims Before the Final Report

  • Observed problem: Unsupported specificity and overstated frames could enter a report because they sounded coherent.
  • Reasoning: Evidence, counterarguments, and claim boundaries needed a verdict before final composition.
  • Implementation: The research workflow issued repair before report, fixed or removed claims, and passed only the narrowed conclusion forward.
  • What changed: One AI-power research case moved from a broad global-shortage frame to a defensible question of local time-to-power: securing, connecting, cooling, and operating capacity where it is needed.

Agent App Extensibility: Add Executable Structure, Not Just a Prompt

  • Observed problem: A role description alone did not define inputs, tools, examples, tests, or where usable results should go.
  • Reasoning: A reusable agent should behave like an installable app.
  • Implementation: App manifests, input contracts, deterministic tools, examples, tests, and output validation were packaged together.
  • What changed: New problem domains could be installed and reviewed inside the same workspace model.

Inspect the Work

Next caseSajuBase