AiVIS Desktop Light

A trusted AI partner that reasons from evidence, remembers with permission, and acts within owner-controlled authority.

Comment

AiVIS Desktop Light

Watch an agent read four local project documents, produce a decision brief, write real Windows files inside an owner-delegated boundary — and lose that authority when the owner revokes it.

The problem

AI agents are becoming increasingly capable of reasoning, planning, and proposing actions. But model capability and permission to change a real machine are not the same thing.

AiVIS Desktop Light explores a simple question:

How much autonomy can we give an AI agent without giving up control?

The design separates cloud reasoning from local authority. Gemini can help reason over project context, but a model response does not automatically become permission to mutate the Windows machine.

What AiVIS does

AiVIS Desktop Light is a Windows agent prototype built for the Collaborative Partner track.

In the recorded demo, AiVIS:

  • reads four local project documents,
  • combines them with approved Memory and provenance,
  • produces a Project Decision Brief,
  • exposes the supporting evidence in an Evidence Drawer,
  • requests Owner approval before a real Windows filesystem side effect,
  • accepts a narrow and revocable delegation,
  • executes automatically while a request remains inside that boundary,
  • falls back to Approval when the boundary is crossed,
  • loses delegated authority after Revocation,
  • and records durable Receipts showing what happened and which authority allowed it.

The demonstrated delegated boundary is deliberately narrow:

windows.file.write → create_new_only → decision_brief → current project → demo/ → .md

The file operation itself is simple by design. What matters is the change in authority around it.

Memory and evidence

Memory is useful context, but Memory is not authority.

Approved Memory can be supplied alongside project evidence when a later request is processed. Revoked Memory is no longer treated as active context.

The repository also documents one paired observation from the demo process.

In an earlier take, the prompt explicitly named four section headings. In the recorded run, those heading instructions were removed while the approved Memory remained in the request context. The new brief still separated established facts from uncertainties using headings selected by the model, while a previously prompt-requested Critical Risks section disappeared.

That observation is consistent with approved Memory being part of the request context.

It does not establish that Memory caused the difference, and it is not presented as a statistical or deterministic benchmark.

From Approval to Delegation to Revocation

A consequential local action moves through a separate authority path:

Registered Capability → Capability-specific Validator → Final Authority Gate → Capability-specific Execution → Receipt

The Final Authority Gate applies Approval, bounded Delegation, final Revalidation, and Revocation.

For the demonstrated boundary, the authority seam is implemented and tested end to end.

A registered capability without its required validator cannot fall through to execution. The seam fails closed.

That does not mean arbitrary future capabilities automatically inherit safe authority. A new executable capability would still require its own validator, dispatch/executor binding, and Receipt/provenance binding.

Capability can expand. Authority does not expand automatically.

Google technology

AiVIS Desktop Light uses:

  • Gemini 3.5 Flash
  • Google Agent Development Kit (ADK)
  • Google Cloud Run

The Windows Desktop assembles local project context, approved Memory, Evidence, and provenance.

A bounded reasoning request then travels through:

Google Cloud Run → Google ADK → Gemini 3.5 Flash

The cloud sidecar returns reasoning or a proposal. That response is useful context, but it is not local execution authority.

Reasoning can leave the desktop. Authority does not.

Architecture

The architecture deliberately separates two paths.

The reasoning path handles project context, Memory, Evidence, provenance, Google ADK, Gemini, and Cloud Run.

The authority/execution path handles:

Registered Capability → Capability-specific Validator → Final Authority Gate → Windows File Executor → Receipt

Keeping those paths separate prevents model capability from silently becoming local machine authority.

The architecture diagram is included directly with this submission. The public repository also contains the same diagram together with reproducible setup, build, deployment, and qualification instructions.

Data sources

The demonstrated reasoning task uses local project documents and Owner-approved Memory supplied through AiVIS.

The Evidence Drawer keeps the context inspectable instead of presenting the generated brief as if it appeared without sources.

What makes it different

The project is not trying to prove that an AI agent should ask a human before every action forever.

That would remove much of the value of autonomy.

Instead, the Owner defines a narrow boundary and the agent receives room to act inside it. That boundary remains inspectable, constrained, and revocable.

Receipts then preserve accountability for consequential actions.

The resulting model is:

The agent works autonomously. Authority does not.

Limitations and what I am not claiming

This submission intentionally keeps its claims narrow.

  • windows.file.write with the demonstrated create_new_only flow is the consequential capability implemented end to end here.
  • MCP, calendar, research, and coding agents are not claimed as implemented Desktop Light capabilities.
  • The routing layer here is not presented as a sophisticated general-purpose router.
  • Arbitrary new capabilities do not automatically receive safe execution authority, and the paired Memory observation does not prove deterministic or statistical control over model output.
  • The Windows path boundary does not claim elimination of every privileged TOCTOU/name-swap race, and filesystem mutation plus SQLite Receipt persistence are not one globally atomic transaction.

Where the evidence stops, the claim stops.

Findings and learnings

The most important lesson from building AiVIS Desktop Light was that autonomy and authority do not need to grow together.

A capable model can reason broadly while the execution layer remains narrow and explicit.

I also found that a capability registry alone is not enough. Safe expansion requires the validator, execution binding, authority decision, and Receipt/provenance path to remain connected as one contract.

Finally, evidence and accountability need to survive beyond the model response. The Evidence Drawer helps expose what entered the reasoning context, while Receipts describe consequential actions after execution.

Pre-existing work disclosure

AiVIS Desktop Light is a separate Windows-focused hackathon project, but it has architectural lineage from broader pre-existing AiVIS work.

Selected D3/D4/D5-era reasoning/provider, Memory, Approval, and Receipt modules contain adapted lineage and are not presented as entirely new hackathon-period work.

The D6 Windows Local Executor was newly implemented for Desktop Light.

Later submission hardening selectively incorporated and reimplemented security and authority patterns informed by the broader AiVIS codebase. That later hardening lineage is distinct from claiming that the Windows Executor itself was copied from an existing executor.

The public GitHub repository is a sanitized submission snapshot.

Repository: https://github.com/AiVIS-OS/aivis-desktop-light

Demo: https://youtu.be/MyBlV4Pl_5o

Social post: https://www.instagram.com/p/Dctk3pdj0SK

Built With

Share this project:

Updates

Submission history