Profiles
Choose approved models, providers, local capacity, budgets, residency, and retention per Product or environment.
AI architecture
One AI control point. Capacity where it makes sense.
GlobalStacks separates AI application work from model-provider credentials and infrastructure details. Teams use a logical AI Gateway profile while policy can route requests to approved providers or private capacity on hosts they operate.
The operating model
Build once against a gateway, not a collection of model keys.
A Product, environment, or AI agent selects one explicit gateway profile. That profile owns the approved models, provider connections, budget, residency and retention policy, and any private inference capacity that may serve the request.
Connections
Keep provider credentials in the broker boundary. Workloads receive a gateway profile, never a provider key.
Routes
Resolve each request against one explicit profile, model alias, policy, and capacity decision.
Receipts
Record content-minimized route evidence for operations, cost, and policy review without turning prompts into control-plane logs.
Request path
profile: product-production
Product or Studio agent
Gateway profile + approved model alias
GlobalStacks AI Gateway
policy, budget, routing, receipt
one route
Approved provider
Brokered credentials
Private local worker
Typed host path
gateway_profile product-production
model_alias approved-chat
route: policy-selected capacity
Local AI capability
Use your hardware without turning it into a public model endpoint.
No provider payment is required for requests served by your approved local capacity.
You still own the hardware, power, and operations cost. GlobalStacks makes that capacity governable rather than invisible.
Use capacity you operate
Connected hosts can contribute approved CPU or accelerator capacity instead of forcing every request through a remote provider.
Keep workers private
Inference workers stay behind typed agent and mesh paths. Their ports, management APIs, model files, and credentials are not application endpoints.
Choose deliberately
A profile can select an approved external provider, private local capacity, or a policy-defined fallback. The application keeps one gateway contract.
Clear boundaries
The app asks for intelligence. The platform decides how it is served.
Applications and agents
Choose a gateway profile and a model alias. They do not choose provider credentials, worker URLs, raw accelerators, or engine flags.
AI Gateway
Applies model and provider policy, budgets, data handling, route selection, capacity admission, and route receipts.
Connected host
Reports eligible capacity and runs approved private workers through typed lifecycle operations.
Move from the cloud to the edge
Run AI where the work already is. Keep cloud capacity when elasticity is useful.
GlobalStacks does not ask a team to make one permanent infrastructure choice. A gateway profile gives the same application contract whether a request is served by approved provider capacity or a private worker on infrastructure you operate.
Your data is already private
Keep inference near internal services, repositories, databases, and network boundaries instead of creating a new external data path for every request.
You already own the capacity
Put underused CPU or accelerator capacity to work with explicit scheduling and limits instead of paying a second runtime bill for steady workloads.
Latency is part of the product
Avoid a round trip to a remote region when the application, retrieval source, or human workflow is already local to the selected host.
Cloud still earns its place
Use approved provider capacity for burst demand, models that do not fit your hardware, managed regional availability, or teams that do not want to operate inference workers. Profiles can make that choice explicit without changing application code or scattering provider keys.
The practical default
80%
of recurring, well-bounded business requests can be a local-first design target.
Design for the work people actually repeat
Local AI for the common path. Larger models for the exception path.
Many business workflows are recurring and constrained: summarize a known report, classify a familiar request, retrieve from an approved knowledge set, prepare a standard response, or operate within a defined process. A well-designed prompt, tool boundary, and local model can serve that common path close to the data and at predictable cost.
The goal is not to force every imaginable question through a local model. Novel, ad hoc, or out-of-domain work can be routed to an approved larger model through the same gateway profile. That is an explicit exception path, with its own policy and receipt, not the architecture every routine request must inherit.
What the 80% means
It is not a claim that a small local model can answer 80% of every question people could ask. It is a product-design hypothesis: identify the repeated requests in a specific business workflow, give them curated context and clear instructions, measure quality, and make that reliable path local-first. Keep escalation to larger models available for the work that does not fit.
Availability
Start with governed provider routing. Add local model capacity as it is certified for your host.
Gateway profiles, provider connections, model aliases, route receipts, and private local execution foundations are in active delivery. Model-worker runtimes, accelerator lifecycle, scheduling, and additional engine support are enabled only where their typed host contract and verification coverage are complete.