04/06/2026

What should WindieOS become?

WindieOS should be a control plane for a user’s devices, including desktops and mobile devices. Each device should usually have one primary local agent responsible for that device. Spawning additional agents should be an optional feature, not the default architecture.

Each device agent should be able to communicate with other device agents through a dedicated agent-to-agent communication channel. I do not mean hidden tool routing where one agent silently calls another device as a tool. I mean agents should be able to message each other conversationally, similar to how a user talks to an agent, but in a separate medium from the user-facing chat.

For example:

- Agent on Peter_Macbook asks: “What project are you working on?”

- Agent on Peter_Windows answers: “I’m working in the WindieOS backend right now.”

- Peter_Macbook agent says: “I changed frontend code that needs backend support. Can you fetch the branch from GitHub and restart the backend?”

- Peter_Windows agent does the work and reports back.

WindieOS also needs a proactive wakeup system. Right now agents wake up only when the user sends a message. There should be periodic polling or scheduled wakeups so agents can check relevant state, continue work, coordinate with other agents, and decide whether the user needs to be notified. If one agent wakes up and decide to send a message to another agent, that other agent is woken up.

Side notes:

- Agents should choose when to notify the user.

- The system should stop treating every normal assistant text token as user-visible output.

- There should be separate channels for user-facing messages, agent-to-agent messages, internal status, and tool/system events.

Ideas / device-resource model:

Peter

  Peter_Macbook

    WindieOS repo / frontend work

  Peter_Windows

    Downloads

    WindieOS backend work

  Peter_Phone

    Albums

The ideas section is meant to show that WindieOS should understand a user’s devices and their local resources. Each device has its own primary agent, and those agents can coordinate by talking to each other.

Agents with a long-running tool call loop will compact its conversation multiple times. This feature is very lossy, can lose important information. So an agent given a task should have one source-of-truth task document to work with so that the key task content doesn’t get lost or repurposed during multiple compactions, the agent should read this always before doing anything.

Side note: The Agent should know what agents are available too. 

Possible new workflow: create an instruction in AGENTS.md, for any moderate to major changes, based on the user’s instructions, construct a plan in task.md that describes what to do, give a checklist, success criteria. After creating task.md, stop and ask the user for confirmation, describe to the user what will be changed in bullet points in an architectural, conceptual manner, modify task.md if the user wants to change, proceed and mark each success criteria, checklist as done if the current code achieves the criteria, checklist. Don’t stop until all the criteria, checklist is done.

Current AI problem:


You are a transformed-based Large Language Model, you have a limited context window. As a result, a lot of practices have been made so you could maintain a persistent memory as you develop in a large codebase. One of the most popular practices is history compaction when the context length reach a certain threshold (90%). This creates a problem: after the compaction, you lose a lot of information and might diverge from the intended specific task at hand. As a result, you might complete the task in a generic, unfinished way. In order to solve this, I have developed a method that always keep you grounded to the specific plan. Before coding, you create a refactor plan. The plan is the pre-flight execution contract. It must restate the user intent, describe the architectural change conceptually, name out-of-scope work, provide an ordered plan, checklist, success criteria, validation commands, and assumptions. After writing the plan, stop and ask the user to read and approve it before proceeding. Explain the proposed change in architectural, conceptual bullet points: what source of truth changes, which runtime boundaries move, what old path is deleted or preserved, and what behavior must not regress. If the user changes direction, update the plan file first. The plan shouldnt be one deterministic set of changes to implement, rather a workflow to read the code and identify the code to change until the intended purpose is fully achieved and the agent loop should only stop then.

You should end your turn only when after you inspect the code and find nothing to change. If you found something to change and finish changing it, you always have to keep inspecting the code until you find nothing to change.

When you notice your history is a sign of a compacted summary, always read the refactor plan and realtime report first to gain the true context before coding.

Giving myself a little note: I got until June 10 to release WindieOS

so for the path that the user enables the camera button and it auto takes a screenshot and attachs it with the user message, or even when the user attachs a file during the user message using the add button.

For camera button enabled:

renderer request image capture -> electron main call the sdk to execute the screenshot -> sdk returns the screenshot -> electron main hands the screenshot back to the renderer. Before this point, after sending a image capture request, the render should wait for the screenshot, then add that screenshot with the payload that the renderer is about to send to electron main, which includes the user message and that screenshot.

for file attachments:

it should be the same, if its a txt, or pdf, or some text file that the read_file function supports, renderer request read_file for that specific path-> electron main callls one of the sdk functions to execute read file on that path, sdk returns the output -> electron main hands the output back to the render. same thing goes for image attachments

so the sdk should be supported to execute functions, do a bunch versatile stuff.

electron. main calling the sdk functions

const output = sdk.screenshot() // this is conceptual code, sdk should be simple like this

question, for the chat history storage, there is user messages, assistant messages, and then the checkpoint where the compaction summary is present. so for example:

user : hi

assistant: hello

user: do stuff

tool calls

tool outputs

bla bla bla

[hit threshold]

#1 compaction summary

[continued conversation]

[hit threshold]

#2 compaction summary