Why INGRA Failed and What I Built Instead

I built INGRA to give an LLM full access to my computer. It wasn't just a chatbot or an API, It was a real agent, but it was a virtual proxy that could read emails, access the web, write scripts, and manage things instead of me. But after only six months, it failed because of two walls that I couldn't cross.

The Dream

INGRA was straightforward: curate callable functions, expose them via OpenAPI, let the LLM decide which ones to invoke. Auto-generated Swagger docs. LangChain integration. Clean developer experience.

I built the function hub, the execution layer, the chat interface. It worked.

Then reality hit.

---

Wall 1: Node VM Is a Lie

I restrict the scope of functions within the virtual machine mode of the program It makes me feel safe, secure and responsible, However, the abstraction leaked everywhere, and I couldn't launch a headless browser because the virtual machine doesn't have access to the real resources of the system I cannot write data down in the file system without going through a complicated process Every edge case needed a workaround, and every workaround introduced fragility The more I try to enforce the limitations it becomes clear that this limitation is protecting me from the capabilities I want to use I wasn't building an agent, I was building a cage

---

Wall 2: $3,000 for an OAuth Checkbox

I want INGRA to read only emails in my Gmail, not other people's emails for use in setting up personal automation on my machine, but to request access to emails via Google's OAuth requires a security assessment, which costs up to $3,000 per year for my personal project. I stared at the pricing page. When I saw the price and I closed my laptop and walked away, that was the end of INGRA

---

The Question That Changed Everything

I'm still thinking about this, but it's not about INGRA - about the absurdity. I can open an email through a browser to read email, copy, forward or delete email normally without anyone charging me three thousand dollars, so why would I need to ask permission for the system to do something that I can already handle myself? The annoying answer is that I'm trying to designed for permission instead of capability. I'm focusing too much on creating a "perfect" system, not so much on OAuth flows, working in a sandbox, or defining clear boundaries that I easily forget the fact that if I can do it, my agent should be able to do it too.

---

The Pivot

I started over.

No sandboxing. No OAuth dependency. No permission-seeking architecture. The new system would run on a dedicated server—my server—with full system access. It would launch browsers, install npm packages, write files, execute shell commands.

It would be me, given a computer.

I called it Vargos.

---

What VARGOS Does Differently

Every failure in INGRA became a design constraint in VARGOS:

The core is built with NestJS, exposing both OpenAPI and MCP endpoints. Functions live in their own repository. Each has a .ts executable and a .json metadata file describing inputs, outputs, and purpose.

The LLM reads the metadata, selects a function, provides structured arguments - and VARGOS executes it.

No gatekeepers. No $3,000 checkboxes.

---

Reading Gmail Without OAuth

Here is the punchline. VARGOS can use IMAP with an App Password, which has supported this function from the very beginning without having to use OAuth, Python's imaplib or Node's imap-simple can handle it, or can automate the browser by persisting a manual session and letting Playwright do the rest, or can parse the local mail client cache if Thunderbird is already syncing and then all these methods can be done for a long time, but I don't see it because I am only focused on designing the "right" system itself Every one of these approaches was available from day one.

---

The Real Failure

INGRA didn't fail because of the limitations of Node VM or the cost of OAuth, but it failed because I designed the system I thought I should build instead of designing to solve the problem I actually had I wanted an agent that could do things but I built a platform that asked for permission, the $3,000 fee was the best thing that ever happened to me because it forced me to stop and ask what am I really trying to do? and the answer is always the same that if I can do it manually, my agent should be able to do it too. VARGOS is that answer.

---

The Industry Caught Up

When I built INGRA, "tool calling" was an OpenAI-specific feature. You structured your functions their way, used their SDK, and played by their rules. Later, the industry evolved when Anthropic released the Model Context Protocol or MCP as a provider-independent standard for connecting LLMs to external tools and data sources. VARGOS now exposes both OpenAPI and MCP endpoints, allowing the same functions to work with Claude, GPT, or any model that speaks the protocol. This is also how I code from my phone - VARGOS handles tasks via WhatsApp while I am away from my desk. I am a software engineer building an agent that writes, executes, and iterates on code, eventually making my own role optional - that is the goal. The function instrumentation problem I had been solving in isolation suddenly had a shared specification.

As the world progresses, we evolve too - or we get left behind. I want to be an innovator who makes my old job obsolete instead of trying to pretend that nothing changes. This is the trajectory I explore further when I built a voice AI platform - pushing agents even harder toward autonomy.

If You're Building Agents

Before you reach for OAuth, before you sandbox execution, before you design for what platforms need you to do - ask yourself:

What can I actually do right now, without permission?

The answer is usually more than you think. Constraints are not blockers. They are redirects.

INGRA taught me what I wanted. VARGOS is what I built.