Support that lives in the product.

I have opened a lot of support tickets in twenty years of using software, and I can count on one hand the ones that ended with the problem actually understood. The usual ending is quieter: you find the workaround yourself around day three, and the vendor closes the ticket for inactivity a week later. Sometimes a survey arrives afterward asking how satisfied I was. When I started building OMEGA I kept a note about that. If I ever shipped a product, support would live inside it, not in a portal on the other side of a login.

OMEGA is that product now, and this post is about how support works in it: an AI layer that troubleshoots inside the app with the model you picked, at whatever hour things break, and behind it an email address that lands with the founder, not with a contractor reading a script. I want to explain why it is built that way, and where the big-vendor model does better.

Ticket theater

You know the genre. Something breaks, you find the support link, and it routes you to a portal that wants you to create a second account to report that the first one is broken. An autoresponder assigns you a number. A day later a reply asks which operating system you are on, though the form you filled in asked the same question. You answer. Another day passes and you are asked to clear your cache and try again. By the time someone who can read a log file sees your ticket, you have spent a week as an unpaid diagnostic instrument, retyping your setup into a text box one round trip at a time.

The theater is not the people. Support agents are mostly doing exactly what their tooling and their scripts allow. The theater is structural: the person helping you cannot see your machine, so the whole exchange is you describing your setup at one remove, from memory. Every round trip loses detail. The ticket becomes a lossy compression of your actual problem, and the macro library on the other side pattern-matches against the compression, not the problem.

The incentives point the wrong way too. A help desk is a cost center, and the standard way to control a cost center is deflection: a chatbot in front of the contact form, and response-time targets measured on first reply rather than on resolution. None of that is evil. It is what scale forces when support is a department instead of a property of the product.

What the big help desks get right

The hosted model has real advantages that a local-first product gives up.

A cloud vendor runs one deployment. When something breaks, it breaks in one place and the vendor's own telemetry lights up. A fix rolls out to everyone at once, often before most users notice. Their support team sees patterns across the whole user base, so a strange error you hit once may already be a known issue with a documented cause. That is a genuine strength, and OMEGA does not have it. Your OMEGA runs on your Mac. There is no fleet dashboard on my side showing me your configuration, and I think that is the right trade, but it is a trade.

Scale also earns some of the theater. Zapier connects more than 7,000 apps; at that surface area, triage in front of the humans is the only sane way to run a help desk, because the space of possible breakage is combinatorial and no staff could hold it. Self-hosted open source helps in a different way: when n8n breaks for you, the source is right there, and reading it is a form of support no closed SaaS can offer. I respect both answers. They are answers to a different question, though. My question was what support should look like when the product runs entirely on the user's machine and the vendor can see nothing at all.

Support that can see your machine

The local-first weakness points at the local-first answer. If the vendor cannot see your setup, the diagnostician has to live where the setup lives: inside the app, under your approval rules.

So OMEGA ships its support layer as part of the product. When something misbehaves, you describe it to the assistant in plain language, the same way you would describe it to a person, except this respondent can actually look. It reads the real logs and the real configuration that a portal agent would spend four round trips asking you to paste in, because the problem and the diagnostician share a machine. Which macOS version, which providers are configured, whether a key is failing, what an Automation recorded the last time it ran: none of that gets retyped into a text box, and none of it leaves your Mac to be examined.

The support layer is not a canned chatbot bolted onto a help page. It runs on the same Neural-Fractal Agentic AI™ (NFA) engine as everything else in OMEGA, the engine that coordinates its 200+ agents and 5,300+ bundled skills, pointed here at the product itself. It consults the same Diagnostics surface you can open yourself, and it works under the same rules as any other work in OMEGA. If a fix means touching a file or restarting a service, it proposes the change and you approve it, the same per-app approval flow that governs computer use everywhere else. Support gets no special powers. I think that matters: the moment a support tool is allowed to bypass your approvals, it stops being support and becomes a liability with a friendly name.

The privacy line is worth stating plainly. An assistant that reads your machine to help you is acceptable only because it is your assistant on your machine. The identical feature offered by a cloud help desk would be remote access with better branding. Local-first is what makes deep-context support tolerable at all, and the boundary rules live on our security page.

Three in the morning, with your model

A concrete run-through, because the abstract version undersells how different this feels. Say an Automation that fires at six every morning did not fire today. In the portal world that is a multi-day ticket, because the first three replies exist to establish facts your machine already knows. In OMEGA you type: my morning digest did not run.

The assistant reads the schedule and confirms the trigger fired on time. The run log shows the run began and stopped almost immediately. The cause turns out to be your budget cap, reached the evening before, so the morning run was declined rather than allowed to overspend. The assistant tells you that, in those terms, and proposes the two real fixes: raise the cap, or point the Automation at a cheaper model so it fits inside the cap. It does not quietly pick one. Budgets and model choice are yours in OMEGA, so the assistant's job ends at a clear diagnosis and a reviewed change, not a decision made on your behalf.

The whole exchange takes minutes, and every hour of the day is the same hour. That is not a small point. Failures do not schedule themselves inside business hours, and the worst ones reliably pick the night before something matters. An in-app diagnostician has no time zone and no queue.

The model doing this work is the model you picked, which is a deliberate rule in OMEGA and applies to support like everything else: we never silently substitute a different model for the one you selected. Route through a Claude or Codex subscription and that is who troubleshoots for you. Bring your own keys and the diagnosis runs at provider cost, because BYOK in OMEGA carries no token markup. And the local case is my favorite: with a model running through Omega-MLX on Apple Silicon, support works with the network cable unplugged. A local model diagnosing a local product on a local machine owes nothing to anyone's uptime.

Provider outages get the same treatment. When the model you selected is unreachable, OMEGA says so instead of swapping in something else behind your back. And because memory in OMEGA is provider-portable, you can switch providers mid-conversation and keep the entire thread, including a half-finished diagnosis. The 4-layer memory and the Brain knowledge graph belong to you rather than to any one vendor, so a support conversation survives a provider having a bad day.

Then a human

The in-app layer will not fix everything. Some failures are genuine defects in OMEGA, and some questions no diagnostic can answer. For those, there is email, and here is the whole policy: support email is read in-house, by the shop that builds the product. OMEGA is a founder-led company. There is no outsourced help desk, no distant tier one working from a macro library, no portal account to create. You write a plain email describing what happened, and it is read by someone who works on the actual code.

I will be straight about the trade. A founder-led inbox does not come with a call center's round-the-clock response guarantees, and I am not going to invent one here. What it comes with is depth on the reply. The person reading your email can open the code the same day, and when your report exposes a real defect, the fix ships to the product in an update instead of settling into a macro as a documented workaround. In the ticket-theater model, the help desk and the engineers are separated by a queue and a quarter. Here they are the same inbox.

The two layers feed each other. Because the in-app assistant absorbs the routine failures, the email that reaches a human is the rare and interesting one, which is exactly the kind a builder wants to read. And if you choose to attach the diagnostic transcript, it arrives already structured: what was checked, what was found. Nobody asks you to re-describe your setup, because the layer that could see your setup already did.

Support is a product surface

The belief underneath all of this is that support is not a department you staff. It is a property the product either has or lacks. Software that can explain its own failures needs a fraction of the support apparatus, and every hour spent making failure states legible inside the app removes entire categories of ticket at the source. That is where the support budget goes here: into error states that name their actual cause, and into an assistant that can look before it guesses.

If you evaluate OMEGA, evaluate this claim directly. Break something. Ask the app why. The docs are there if you prefer reading, and plans live on the pricing page. But the pitch for our support is that you should rarely need to meet it, and that when you do, it should already know where you are standing.