TrueFoundry governs model access and agent tools alongside AI deployment

TrueFoundry provides infrastructure for deploying AI workloads and controlling how applications reach models, tools and agents. AI Gateway centralizes model and tool access, while AI Deploy addresses the workloads that run behind those interfaces. Its acquisition of Seldon’s business and customers brings an established ML-serving lineage into the same company story. The practical decision is whether a shared policy and deployment layer will simplify an organisation’s growing AI estate.

01 / ProductA gateway and deployment platform with an acquired ML-serving business

TrueFoundry's July 2026 acquisition announcement states that it acquired Seldon's business and customers. It describes continuity for existing ML workloads and a transition toward TrueFoundry's platform. The announcement is evidence of the ownership and direction; it does not establish that every legacy customer's migration is complete.

The AI Gateway overview describes a common interface for model providers, request logging, routing, quotas and tool access. Its purpose is to move repeated infrastructure decisions out of each individual application. A team can define how a service reaches permitted models without distributing provider credentials to every developer and application component.

AI Deploy addresses execution of ML and agent workloads, while Agent Gateway and the TrueForge harness extend the offer around agents. These are related parts of the platform with distinct commercial scope. A buyer interested only in proxying model requests should not assume it has purchased an entire agent-running environment, just as a Seldon customer should verify its actual transition plan.

02 / AudiencePlatform teams coordinating many models and tool integrations

TrueFoundry is relevant when several teams have independently added provider keys, retry logic, logging and tool permissions. That duplication can make a model change easy for one application but difficult to control across the organisation. A shared gateway is useful when it provides a clear contract for allowed models, accountable usage and consistent policy enforcement.

The cost is that the gateway becomes another important operational component. If it is misconfigured or unavailable, several applications may be affected together. Teams should therefore evaluate configuration review, recovery and observability alongside developer convenience. The right architecture depends on whether the organisation is ready to operate and govern a shared access layer.

The Baseten blueprint is a useful comparison when the immediate problem is serving a custom model. The Modal blueprint covers a code-oriented route to cloud compute and AI workloads. TrueFoundry's broader question is how deployed models and external providers are accessed consistently across applications; these concerns can overlap without making every product an equivalent substitute.

03 / WorkflowA proposed controlled assistant across two model providers

Imagine an engineering organisation with an internal assistant that can search documentation and propose a change to an issue tracker. It wants to use more than one model provider while keeping costs and tool actions attributable to the correct team. The following is a proposed design, not a deployment or benchmark performed by Sequenced.

Start with identities. The access-control guide distinguishes model-account managers from users and recommends personal tokens for development and virtual-account tokens for production applications. Give the assistant its own production identity and the models it needs. Keeping its access separate from an employee's personal development token makes revocation and incident analysis clearer.

Map approved model choices to the application interface. The routing guide documents weighted, latency-based and priority-based routing, with retry and fallback configuration. For the pilot, select a primary route and a fallback that has been evaluated on the same tasks. A fallback response that succeeds technically can still violate an output schema or produce a weaker tool decision.

Test the circumstances that actually trigger fallback: provider errors, throttling and delayed responses. Record which target answered and which policy selected it. Do not let fallback silently move restricted prompts to a provider or region that was never approved for the data. The application should be able to explain which configuration served a given request.

Add the documentation search tool with permissions limited to the intended information. Then separate the issue-tracker read capability from any write action. The MCP tool-approval guide describes holding selected tool calls for a human decision, with single-use or time-based grants. The important design choice is the scope of the grant, not simply whether an approval dialog exists.

For a proposed issue update, start with a single-use grant and show the actual arguments to the approver. Test a denied request and a later retry. The documentation says denial does not permanently block future requests; a durable block requires removing access or disabling the tool. The surrounding process should not mistake a denied request for a lasting change in the assistant's authority.

Ensure the client recognizes the pending state. The documented response can be a successful JSON-RPC result with approval metadata even though the tool was not executed. An application that interprets transport success as completed work could tell a user that an issue was changed when it was only waiting for approval. Read the approval state and verify the eventual tool result before reporting completion.

Choose where the gateway and logs live using the deployment options. The documentation distinguishes managed service, customer-controlled storage and privately hosted components. Customer storage does not necessarily mean data never passes through a vendor-operated component; the described architectures have different access paths. Draw the actual request and log flow for the selected mode before sending sensitive traffic.

Finally, compare total gateway calls with completed assistant tasks. One user request can cause multiple model requests and tool calls. Attribute them to the assistant's production identity and application version so a cost increase can be connected to a longer reasoning loop, a new tool pattern or changing user activity. The pilot should prove both useful behaviour and an understandable operating bill.

04 / PricingSeats buy access while requests determine gateway overage

The TrueFoundry pricing page, consulted 23 September 2026, lists Developer as free for up to three users with 10,000 requests per user per month. Pro is $25 per user per month and includes 20,000 requests per user per month, pooled across the team. Additional usage is listed at $20 per 100,000 requests. Confirm billing currency, taxes and overage rounding in the account.

The page counts client LLM requests and MCP tool calls alike; internal gateway retries and failed calls are described as excluded. Provider model charges and external guardrail charges are separate. Therefore an allowance of gateway requests does not include an equivalent quantity of free model inference. Plan the bill in layers: platform seats, gateway usage and the providers or compute executing the work.

Agent Gateway and Agent Harness have custom pricing on the current page. Deployment documentation also still uses a Starter label, while the pricing page names Developer and Pro. We use the current pricing names and do not infer an entitlement mapping from the older label. Resolve the selected deployment and any AI Deploy or agent-product scope in the actual order.

05 / DistinctionsCentral control is valuable when its scope is explicit

The useful distinction is the combination of model routing and tool governance around an existing application estate. A shared identity can connect policy decisions, usage and access to both models and tools. That offers platform owners a place to manage repeated operational choices, while developers retain responsibility for the application behaviour users actually experience.

The Seldon relationship also matters for organisations already running classical ML. The acquisition announcement frames a path from established Kubernetes inference toward agent workloads under the same vendor. Our assessment is that continuity is a valuable discussion, but it should be evaluated using concrete compatibility and support commitments. An acquisition announcement is not proof that a particular deployment can migrate without changes.

06 / QuestionsCheck bypass paths, client semantics and deployment boundaries

A gateway controls the calls that reach it. If an application can use a provider key or tool credential directly, the organisation needs to decide whether that is permitted and how it is observed. Test the actual application configuration, including development environments and background jobs, before concluding that a central policy applies to every request.

Check how applications handle pending approvals, expired grants and changed fallback routes. Also verify the chosen architecture's log access and retention. This review did not measure gateway latency, test private hosting or validate Seldon migration compatibility. Treat published performance and savings figures as vendor claims; a representative load test and a review of concrete migration requirements are more useful for a deployment decision.

07 / DecisionAdopt a shared layer when it creates clear ownership

TrueFoundry is worth evaluating when model and tool access have become a cross-team operational problem. Begin with one production identity, a tested fallback and one controlled write-capable tool. Demonstrate attribution, failure handling and an accurate bill before broadening the rollout. For existing Seldon customers, make continuity and migration support explicit parts of the decision alongside the new agent capabilities.