How it works
Ten stages, in order
MKSTVEFX is a platform around a model rather than a wrapper on one. This is what happens between typing a request and getting something useful back.
You ask for something
A question, a task, or a piece of work with a deadline attached.
The conversation, the project it belongs to, and any sources you attached are the inputs. Nothing else is pulled in silently.
MKSTVEFX reads the request
It works out what the task actually needs — a search, a file, a calculation, your calendar.
What a task needs decides which capabilities the model must have, which is what makes routing a decision rather than a preference.
The router picks a model
Your local model, or a provider you connected with your own key. If the task needs a capability the chosen model lacks, it says so instead of guessing.
The gateway normalises messages, streaming, tool calls, structured output and errors, so the model is a choice rather than an architecture. The response records which backend answered.
The model requests a tool
It cannot reach your data directly. It names a tool and supplies arguments, which is a request, not an instruction.
The model can request an action. It cannot grant itself the permission to perform one — that permission is a row in the database, not a sentence in a prompt.
MKSTVEFX checks the request
Arguments are validated, your permissions are checked, and budgets and timeouts apply. Anything with a real-world effect stops here and waits for you.
Project rules apply here too: a project may be restricted to certain connectors, or to none, and that narrowing is enforced before anything is called.
The tool runs
A web page is read, a connector is called, a memory is retrieved — under your credentials, within the scopes you granted.
Credentials stay on the server, encrypted at rest. A connector used for search never asks for permission to send.
External content is marked
Anything written by someone else is treated as untrusted from that moment on, and every later action that has consequences needs your approval.
This is the defence against prompt injection: text arriving from an email or a web page cannot quietly raise what the run is allowed to do.
Memory is consulted and updated
What is relevant is brought in; what proves useful is kept, with a record of where it came from.
Every memory carries its source, its date and the inputs behind its confidence score. Unrelated private information is not included because it happens to be stored.
The result becomes something usable
A table, a chart, a draft, a document — rendered by MKSTVEFX, with its sources and the time it was gathered.
A widget states whether its data is static, polled or live, and says so when it has gone stale rather than showing an old number as a current one.
You decide what happens next
Nothing leaves the building without you saying so.
The approval names the exact action and the exact arguments. Approving “send this email to Ana” does not authorise sending it to anyone else, and the decision is recorded.
What the loop is not
It is not autonomous. A task runs within a budget you set, using permissions you granted, and stops at anything consequential to ask. That is a deliberate limit, not an unfinished feature — an agent that can act without asking is one you have to supervise anyway, and supervising it is more work than doing it.