Where AI agent work actually runs

In loqy V1, the engine, model, and tools occupy distinct zones: each sees only the data and permissions assigned to it. This separation puts loqy's local starting point into practice.

Consider one request:

Read the notes and contracts in Project Atlas, research public warnings about its three main suppliers, compare the risks, then deliver a sourced brief with recommended actions.

The project files are local. Research calls external services. Analysis can use a local or hosted model. The browser and document tools need to handle potentially hostile content. The deliverable must return to the work with its sources.

Following this request explains the loqy V1 architecture more accurately than a single “local” or “cloud” label.

In brief

Model placement and agent-engine placement are independent choices. In V1, a hosted model generates remotely, while the Core, workspaces, tools, and business authority stay local.

Six components, six responsibilities

Local agent engine

The engine orchestrates the work. It opens a run, selects admitted context, assigns an exact model, exposes a closed set of tools, checks permissions, and records results. In loqy V1, that authority belongs to the local Rust Core.

The engine defines which capabilities exist. The model proposes text and tool calls inside those capabilities.

Local model

A local model generates on the Mac. It receives context assembled by loqy; files, network, and credentials remain behind Core capabilities.

Hosted model

A hosted model generates through the selected provider route. Under that provider's terms, the computation may run directly or through a third-party inference provider permitted by those terms. The context needed for generation crosses the network, while the engine and work remain local.

Isolated tool

The browser, code, scripts, document tools, and untrusted local MCP servers run inside an Apple Containerization microVM. The Core grants only the mounts, network destinations, and capabilities scoped to the run.

External service

A search engine, business connector, or API receives a request suited to its role. The conversation and files remain under Core selection.

Remote execution

A remote run would move the engine, state, and tools to cloud infrastructure. This is a different architecture, outside the V1 execution path. The diagram presents it as a separate zone from a hosted model.

What each component can see

The diagram shows placement. The following table describes what crosses each boundary.

A hosted model can receive sensitive content when the user selected that generation and the content is needed. That admitted context does leave the Mac. The provider does not thereby receive credentials, complete workspaces, or tool permissions.

Step 1: the Core opens an exact run

The Atlas request arrives in a local thread of work. The Core creates a run with its own identity and state. Only one run can be active in that thread at a time.

The Core then fixes a RunModelLease. This lease names an exact model, its local or hosted placement, any provider, and the necessary parameters. It remains immutable during the run. A failure therefore does not silently replace the model.

The lease attributes every output to the model that produced it. It also prevents a routing change from altering the data boundary during the work.

Step 2: context is assembled locally

The model does not open directories for itself. The ContextPlanner, under Core authority, assembles usable context from the request, relevant history, authorised files, and tool results.

For Atlas, it may select:

• the user's request;
• contract passages describing continuity commitments;
• internal notes about each supplier;
• public results returned by research;
• deliverable rules and the available tool capabilities.

Context selection is an explicit, testable mechanism. Content sent to a hosted model is the admitted context for that generation.

Step 3: tools work inside the microVM

Contracts may be PDF or Office files. Researched pages can contain scripts or instructions designed to manipulate an agent. This content should not grant a host process the same rights as the user.

loqy therefore attaches an isolated microVM to the request. Untrusted processing receives only the resources it needs: policy-controlled mounts, a private workspace, temporary memory, and network access to authorised destinations.

Isolation limits each tool's reach. A hostile page can mislead a model, a parser can return a wrong result, and an authorised destination can return malicious content. The Core retains authority and treats these results as data to verify.

Step 4: research crosses its own boundary

To find public warnings, loqy turns the need into bounded queries, such as a supplier name, incident type, and time range. The contracts remain in local work context.

The external service receives those queries and returns results. The isolated browser can then open an authorised page. Useful excerpts, dates, and addresses return to the work as tool results.

Research and model choice remain independent. A local analysis can use web sources. A hosted model can work without research when the supplied context is sufficient.

Step 5: the model receives admitted context

If the user chooses a local model, the context goes to the inference engine on the Mac.

If the user chooses a hosted model, the Core uses HostedInferenceRelay. The relay applies the provider's fixed route, adds the credential held in macOS Keychain, enforces limits, and transmits the request. The credential authenticates the connection but is not injected into messages addressed to the model.

The provider sees the content admitted for generation and service metadata required by its API. The API key remains in the adapter, separate from model messages.

Code enforces the credential boundary. A system-prompt instruction does not. A secret that appears in context can be copied, while a secret held by a separate adapter is unavailable to the model.

Step 6: the response returns to local authority

The response from a local or hosted model returns to the same thread as a proposal to verify.

The Core can present it as text, request a tool call from the run's closed set, or prepare an artefact. A consequential action, such as publishing the brief or messaging a supplier, needs its own permission and contextual decision.

For the Atlas brief, the final paragraphs are only one part of the result:

• the files and passages used;
• the research performed and its destinations;
• the retained tool results;
• the exact model attributed to the analysis;
• human decisions;
• deliverable revisions.

The model contributes to reasoning. The local engine preserves the chain that makes revision possible. The article on evidence explains how that chain connects sources, tools, decisions, and deliverables.

Separate zones make authority verifiable

Separation limits the reach of a model error or hostile instruction. Each component receives the minimum required for its responsibility.

loqy separates zones to reduce that reach:

• the Core owns authority but does not execute untrusted content;
• the microVM executes tools but owns neither business state nor secrets;
• the model receives context but no ambient capability;
• a provider adapter holds a credential but does not organise the work;
• an external service receives one operation, not the whole conversation.

Contracts between zones add crossings. In return, each responsibility can be audited, tested, and replaced separately.

What qualification verifies beyond the topology

The diagram describes intended authority and the paths between components. Qualification verifies that topology on the signed, installed artefact, its network policies, mounts, provider routes, logs, and evidence.

Compute location and authority

The Atlas brief can combine a local conversation, local model, isolated web research, and hosted model. They do not become four separate products. They form one body of work because the local Core retains state, rules, and evidence.

Where does loqy run? The precise V1 answer is: agent authority runs on the Mac; untrusted tools run in a microVM; the model can be local or hosted; external services receive only the operations addressed to them.

Selecting a remote model moves a computation, while the work and its authority remain with the local Core.

Sources and method

• loqy, architecture overview
• loqy, run steering and model selection
• loqy, context planning and compaction
• loqy, hosted-provider onboarding
• loqy, Core-owned capability and context
• loqy, threat model

V1 descriptions follow its product and architecture contracts. The remote engine is documented as a distinct later architecture.