𝗧𝗵𝗲 𝗣𝗼𝘄𝗲𝗿 𝗼𝗳 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 I used to think making my AI assistant smarter meant adding more tools to the same loop. That worked for a while. But then my assistant had to do normal user tasks like continue a task from chat, answer a status question, or remember a desktop workflow.

The problem was no longer about how many tools one agent could call. The problem was architecture. My old architecture was simple:

This is fine for a demo, but not for a resident assistant. A resident assistant needs to know if a message is a new task, a follow-up, or a cancellation. It needs to avoid stealing the desktop from another task. It needs to remember procedures without using every old transcript.

So I stopped thinking about the assistant as one agent. I started treating it as a local control plane. Now my architecture looks like this:

I also have an Observation Plane and a Memory / Policy Plane. These planes have practical boundaries. The experience plane owns where the user is talking from. The assistant control plane decides what kind of work this is. The runtime execution plane does the actual coding work. The proxy/model access plane handles provider work.

The biggest improvement came from making my assistant consume observations instead of raw logs. If a task is waiting for approval, my assistant sees a compact fact: "Task X is waiting for approval to run command Y."

I learned that "remembering" is not the same as stuffing more chat history into a prompt. For my assistant, memory is file-based and scoped. It can store a workflow, a fact, or a reference. On the next similar request, the prompt only gets a small memory index.

If you are building agents around existing tools, are you putting everything inside one loop, or are you starting to split control, execution, observation, and memory too? Source: https://dev.to/codekingai/my-ai-assistant-needed-a-control-plane-not-a-bigger-loop-15aa