# Building VARYN: Why Permission Boundaries Matter More Than Another AI API Call > Source: > Published: 2026-11-06 08:19:40+00:00 I started building VARYN because I wanted to explore a practical question: how much control should a user have over an AI workspace before it sends data to external models or performs actions? Connecting an application to an LLM API is relatively straightforward. Building a workspace that makes permissions, costs, and failure conditions visible is a different engineering problem. VARYN is my open-source experiment in addressing that problem. The first challenge was separating a user's intent from permission to execute it. A model request should not automatically imply permission to transmit data or spend API credits. In VARYN's current Model Control Center, the owner selects a provider and model, reviews estimated pricing, and explicitly approves the outgoing request. The supported API routes include OpenRouter, DeepSeek, and an optional local 9Router gateway. The application also includes a fake-model mode for testing the interaction without making an external API call. An important limitation: Estimated pricing is not a provider-enforced spending cap. The application cannot guarantee the final bill. I also wanted tasks to persist beyond a single UI session. The current implementation uses SQLite for local task storage, including task creation, status changes, pagination, and due-date tracking. The task store doesn't impose an artificial global limit on the number of saved tasks, although disk capacity and database constraints still apply. What it doesn't do yet is equally important: marking a task as due doesn't automatically execute an external workflow. This distinction helps keep a task tracker from being presented as a fully autonomous scheduling system. Another area I explored was organizing potential application integrations. VARYN currently has a directory of connector, plugin, and skill candidates. However, displaying a service in a directory doesn't mean the user has authenticated it. A real connector needs its own supported authentication mechanism, permission scopes, error handling, and revocation process. The current catalog makes this limitation explicit rather than implying that existing ChatGPT connections can be inherited by an unrelated application. The desktop is built with Python and Tkinter. I created a portable Windows x64 build through GitHub Actions, with the Python runtime bundled so the application doesn't require a separate Python installation. The pipeline includes Windows and Ubuntu checks, along with packaging and hosted Windows GUI verification. That evidence is useful, but it isn't the same as validating every interaction on a real end-user machine. The current binary remains unsigned and experimental. VARYN is not a finished universal AI agent. The larger engineering challenges include durable multi-step execution, authenticated third-party connectors, safe action recovery, stronger local data protection, and a more cohesive model-memory-tool workflow. Native two-way synchronization with the consumer ChatGPT, Claude, and Gemini apps is also not a capability I can claim today. These are meaningful engineering boundaries, not just missing checkboxes on a feature list. The first Windows alpha is available publicly, along with its source code and implementation notes. GitHub: [https://github.com/naraya07pedro-spec/VARYN](https://github.com/naraya07pedro-spec/VARYN) I'd particularly value feedback from engineers working on agent runtimes, API integrations, permission systems, and local-first applications. If you were reviewing this project, which architectural risk would you address first?