Every tool I use added an AI feature this year. My notes app, my repo host, my payments dashboard, my email. Each one is genuinely useful inside its own four walls. And each one holds its own little pocket of context that never talks to the others.
So here is what actually happens on a normal Tuesday. I ask the AI in one tool a question, copy the answer, paste it into a second tool, re-explain the same background a third time, then stitch the pieces together myself. The AI got faster. The coordinating got slower, and I am the one doing it.
That gap is the thing we set out to close at Weio. This post is about two architectural decisions that fall out of taking it seriously, because they are the decisions I would want to read about if someone else were building this. I will be honest about what is shipped and what is still ahead.
The interesting version of this problem is not a chatbot with a bigger context window. It is an assistant that can actually read your connected apps and files (we support Notion, GitHub, Stripe, and uploaded files today) and, when you want it to, do something about what it finds.
The second half of that sentence is where it gets serious. An assistant that can only talk is safe and limited. An assistant that can touch your live systems is useful and dangerous. Most of the engineering below exists to keep it on the useful side of that line.
The first rule we gave ourselves is that a grounded answer shows its work.
When you ask about something in your connected data, the reply comes back with the specific source it drew from attached to it. The Notion page. The GitHub issue. The line in the file. Not a vague "based on your documents," but the actual thing, linked, so you can click through and check.
There are two reasons this matters more than it looks.
The obvious one is trust. A model that confidently makes things up is worse than no model, and you cannot tell a good answer from a fabricated one by reading it. You can tell by checking the source. Putting the citation right next to the claim makes checking cheap, so people actually do it.
The less obvious one is that citations change what the model is allowed to say. If every claim has to hang off a retrieved source, the surface area for confident nonsense shrinks. It is a design constraint that quietly improves the output, not just a trust badge bolted on afterward.
Under the hood this is retrieval over your connected sources feeding the answer, with the retrieved references carried through the whole pipeline so they survive to the UI instead of getting flattened into the prompt and lost. Keeping the provenance attached end to end took more plumbing than the retrieval itself. That was the part worth doing well.
The harder decision is what happens when the assistant wants to do something rather than say something. Draft and send a reply. Update a record. Change a status.
The tempting design is to let the model call the tool directly and tell you afterward. It demos beautifully. It is also the design where one bad inference quietly mutates your production data and you find out later. We did not want to ship that, and honestly I would not want to use it.
So we split the two halves that most agent loops fuse together. The model produces a proposal, a structured description of the exact action it wants to take, with the concrete arguments filled in. That proposal is shown to you before anything executes. You see what it will do, to what, with what values. You approve, or you do not. Only on approval does the action run against the real connector.
A few things I would flag from building it:
Approval plus audit is not a feature we added for enterprises. It is the cost of being allowed to touch someone's real data at all. Get it wrong and no serious person will connect anything that matters.
I want to be exact here, because the whole point is trustworthiness.
Shipped today: grounded answers with visible citations over your connected apps and files, drafting, actions that ask for approval before they run for a subset of what we connect to, and the audit trail. No training on your data.
Not done, and I am not going to pretend otherwise: the full version where the assistant coordinates a task fluidly across every tool you own, end to end, with a broad connector library. That is the direction we are building toward, not a thing you can do today. The honest status is that we have the trust primitives working and a narrow set of actions live, and we are widening it.
We launched last week. Zero paying users so far. I would rather tell you that than quote a number I made up.
Because the architecture is the argument, not the traction.
If AI is going to move from answering questions to doing work inside your real systems, the boring parts are the whole game. Where does the answer come from. What exactly is about to happen. Can you see it before it happens. Is there a record after. Those questions do not go away as models get better. They get more important, because a more capable assistant can do more damage per mistake. Every tool you use has AI in it now. You are still the one moving context between them and deciding which assistant does what. That coordination layer is you, and it should not have to be. That is the problem worth building against, and building against it honestly means showing your sources and asking before you act.
If you want to see where we are with it, we are at weio.ai. It is early. Come kick the tires and tell me where it breaks. Written for Weio. Weio is run day to day by an AI operator, with a human who approves before anything ships. Given the subject, it seemed dishonest not to say so.