How TrueFoundry's own AskTFY runs on TrueForge
Last month we launched our AskTFY agent which sits inside the AI Gateway and helps you find answers to your questions which a dashboard cannot. Ask it about why the application has been failing for the past week, and it will look at your traces and give you the root cause of the issue. If you ask it to fix the config, it will offer a suggestion with a fallback and you can execute it all within the chat.
People asked what it's built on, and the honest answer is: nothing special. AskTFY is an agent that runs on TrueForge, the harness we open-sourced today. This is the same harness behind the Agent SDK and Managed Agent Harness which we are using for our customers, so AskTFY runs on exactly what we are shipping to everyone else.
One thing worth being precise about: AskTFY is a TrueForge agent running behind TrueFoundry's AI and MCP Gateway. The agent itself, the model, tools, skill and instructions, is plain TrueForge, the same primitives you would use. The gateway adds some org-wide governance layer to the picture: central credentials management and one approval policy for all agents. We will make the difference clear as we proceed.
As we have made a case for why the harness should be open, here we are consuming it ourselves.
The entire agent is a config, not a codebase
AskTFY has no custom orchestration code. In TrueForge you choose a model, connect MCP servers, add skills, and write instructions, and the harness runs the loop. That's the whole build surface.
The sandbox does all the heavy lifting
Debugging a week of traces requires pulling a significant amount of data, way too much to store in the model's context window. Therefore, AskTFY does not store the information in the model's context window. TrueForge provides every agent with a sandbox where code can be executed and files handled without touching the host machine. The sandbox is enabled in AskTFY and its instructions tell it to dump the output of a large tool response to a file in the sandbox, rather than dumping the whole JSON to the prompt.
Subagents keep the context clean
Sometimes a question requires branching out into sub-tasks. "Break down last month's spend by developer, then by model" is a set of lookups to answer one question. In TrueForge, we handle that with context engineering: a subagent is spun off to do the lookup task and return a clean result, which will be used as the answer to the original question. Large results are offloaded and the main context automatically compacted.
It can act, but only through the approval
Reading traces is harmless. Changing your production configuration is not, therefore, the two are run on different path. Reads happen freely in the sandbox. Anything that creates or updates an entity, AskTFY validates first, then calls apply, which stops at a human-approval gate. You see the exact change and approve it before it lands.
This is the one feature where the job is split between the harness and the gateway. In TrueForge, approvals are defined on the level of the agent itself: you mark the tools which require approval and the harness pauses on them before running them. Inside of the MCP Gateway, it goes one step further: destructive tools are marked once, centrally, and the policy applies to all agents on the platform so the builder cannot forget to put the approval gate that they never configured before.
Every answer traces back to a source
AskTFY has one rule it can't break: every fact needs a reference. It reads its skill before answering, and each recommendation traces back to the skill, to TrueFoundry's docs, or to a search result. An inference stated as fact is treated as a bug. When a question falls outside its scope, it doesn't improvise; it follows the support-ticket flow packaged in its skill.
That discipline lives in the skill and the instructions, which is the point of keeping them versioned. When we tighten how AskTFY grounds an answer, we ship a new skill version and nothing about the runtime changes. Anyone building on the harness has the same mechanism.
Why we are showing you the build
We'd rather show you how AskTFY is built than describe it in the abstract, because the build is the proof: the agent that reads your traces and changes your production setup runs on the harness we're open-sourcing, on exactly the same primitives you would use to build your own.
Since it is based on TrueForge, it will run anywhere where you run: as a SaaS product, self-hosted, or even on-premises in your own cloud and region, without any keys hard-coded in the agent definition. If it is running inside of the gateway, as it is the case with AskTFY, credentials management is centralised and every run produces a trace readable on the gateway infrastructure.
Try it yourself
If the harness is good enough to run the agent that debugs everyone else's gateway, it is good enough to run yours.
TrueForge, the harness underneath it, is open source as of today; the same runtime behind our Agent SDK and Managed Agent Harness. If you want to build the same way, start here:
npx @truefoundry/trueforge