Give every team the superpower of AI.
One secure deployment puts AI to work across your enterprise, on infrastructure you own, with your data never leaving your walls. Access, limits, audit and guardrails come built in.
A GPU cloud provider is a specialist host that rents dedicated GPU capacity under your own account. Work you restrict to private models stays inside your network, with no external fallback. Work you permit may use approved external providers.
Private, approved external, or both — set per workload.
Repository knowledge shared across coding tasks.
Decisions and agent sessions on one topic.
Every component shares one model-access and context policy.
What runs inside your environment, and what can leave it.
Guardrails
In LatentGateway- L1 pattern and checksum screening
- Block, mask or allow
- Rules set by your admins
Restricted work ends here. It has no route out of your environment and no fallback to a hosted provider.
Permitted work only
Routing sends work you have permitted to an approved third-party provider. Restricted work cannot take this path.
- Inside
- LatentCode, Workspace and SkillPatch; access control, guardrails and routing in LatentGateway; private models on your GPUs.
- Outside
- Approved third-party model providers, only where you have approved them.
- What crosses
- Permitted work, sent by routing to an approved provider. It is the only crossing shown.
- What cannot
- Work you restrict to private models. It has no external route and no fallback to a hosted provider.
Approved third-party providers
Each receives only the inputs you permit, under that provider's terms.
Name the model. See which side of the boundary it runs on.
Self-hosted on your GPUs
Approved third-party providers
Selecting a hosted provider sends the permitted inputs to that provider, under that provider's terms. Restricted work cannot be routed to a hosted provider.
See what crosses the boundaryIdentifiers shown in the provider-prefixed format the gateway accepts. The full compatibility list, with verification dates, is on the LatentGateway page.
Everything the work needs.
Connected in one stack.
Four layers, seven components. Take the whole stack, or only the layers you need.
The human layer: discussions, decisions, a feature wiki and agent sessions around one topic.
Repository knowledge, team practice and the guidance that improves both. Agent-neutral: the context goes to whichever agent you run.
Goal-based agent execution locally or in configured sandboxes, with execution kept separate from model hosting.
One policy substrate shared by every component: endpoints, model tiers, team permissions, and the restricted / permitted split.
The four questions a reviewer brings.
Running on your own infrastructure addresses where data sits. Access, audit and content safety need controls a reviewer can inspect. Each answer links to the page that states it in full.
Where does our data go?
Models can run on your own GPUs. Work you restrict to private models stays inside your network, with no external fallback.
Who can use which model?
Per-user keys, tiers and projects. Rate limits per model and per user, in both directions, enforced at the gateway.
Can we trace a request?
Each request through the gateway is priced, logged and attributed by user, project, model and provider.
What is screened before routing?
L1 pattern and checksum rules screen each input. Admins choose to block, mask or allow.
Choose where it runs. Keep your options open.
Managed service*
We host the platform. Your team gets access to the supported capabilities and an agreed configuration.
HoverTap for detailsManaged service
Platform hosting, managed by us.
On-premises deployment*
Run LatentStack in your environment. Use private models or approved external inference where permitted.
HoverTap for detailsOn-premises deployment
Your infrastructure and model boundaries.
Air-gapped deployment*
Run the factory with locally available models and resources in an isolated customer environment.
HoverTap for detailsAir-gapped deployment
No external model calls in this configuration.
Restricted work stays on private models with no external fallback. Work you permit to use approved third-party models sends the permitted inputs to that provider, under that provider's terms.
See what leaves your environmentBetter context. A measurable difference.
Ask for the full evidence baseFrom a requirement to a reviewed change.
People set the direction. Agents help move the work forward.
Agree the requirement
Clarify the fields, access rules and acceptance criteria. Keep the decision with the topic.
Prepare the work
Bring relevant repository context and team skills to an agent using the permitted model environment.
Delegate implementation
A main agent coordinates persistent side agents. They implement the change and run relevant checks.
Review the result
People assess the change and make critical decisions. The result stays connected to the work.
The practical details.
Do we have to take all of it?
No. An enterprise can subscribe to the whole stack or to individual components.
Does it replace our current coding agent?
Not necessarily. Context can be supplied to supported third-party agents; LatentCode is available when a team wants it.
Does our code leave our network?
It depends on the configuration you choose. Work restricted to private models has no external fallback. Work you permit to use approved third-party models sends the permitted inputs to that provider under that provider’s terms.
Do you train on our code?
No training on Customer Content.
What does it cost?
Platform pricing is per seat; underlying model usage is paid by the customer to the provider. Component-level packaging and consumption terms for managed execution are set during scoping.
Can we evaluate on our own code?
Yes — a scoped POC around one team, one repository and one workflow with agreed acceptance criteria.
LatentStack is at version 0.9. Each component page states its current maturity.
What would you
build next?
Bring a repository, a workflow and your model requirements.
We will scope an evaluation around one team, one repository and one workflow, with agreed acceptance criteria.