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 setup: an AI that can reach your real systems
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.
Decision one: answers carry their sources
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.
Decision two: the model proposes, you approve, the log remembers
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:
- The proposal has to be a real structured object, not a sentence the model wrote about what it plans to do. If the thing you approve and the thing that executes are generated separately, the approval is theater. Same object, shown then run.
- The confirmation has to show the resolved values, not a template. “Send the email” is not a decision you can make. “Send this email, to this address, with this body” is.
- Every step gets written to an append-only audit trail. The proposal, the approval, the result. Not for compliance theater, but because the first question anyone asks when an assistant touches their systems is “wait, what did it just do,” and you should be able to answer that precisely, after the fact, without guessing.
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.
What is actually shipped, and what is not
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.
Why write this now, with nothing to brag about
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.