Notifications
Clear all
Topic starter
21/08/2026 4:54 pm
TL;DR: The agent glossary only becomes operational when each term is mapped to a real production component, TruFoundry argues, because model, scaffold, harness, tool, skill, and sub-agent each imply different governance boundaries. The core lesson is that behavior is shaped by the whole runtime, not just the model, and that is now a control problem as much as a semantics problem.
NHIMG editorial — based on content published by TruFoundry: The AI Agent Glossary, Mapped to Production Infrastructure
Questions worth separating out
Q: How should teams govern AI agents without treating the model as the only control point?
A: Governance should follow the full runtime, not just the model checkpoint.
Q: Why do AI agents create more identity risk than traditional LLM applications?
A: AI agents create more identity risk because they can persist state, choose tools, and carry out actions over time.
Q: What do security teams get wrong about AI governance inventories?
A: They often inventory only the AI they built themselves and miss embedded AI inside vendor platforms and other shadow AI.
Practitioner guidance
- Govern the agent harness as a runtime control Document the loop, approval gates, sandboxing, error handling, and stop conditions as controlled runtime settings rather than implementation notes.
- Separate authorization for tools, skills, and sub-agents Treat function calls, reusable procedures, and delegated reasoning as distinct delegation types with different approval, versioning, and isolation requirements.
- Build an agent inventory from registered definitions Create a canonical registry that records model name, scaffold version, tool grants, skills, and sub-agent references for every deployed agent.
What's in the full article
TruFoundry's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete infrastructure mapping for each glossary term, including where models, MCP servers, skills, and traces live in the platform
- Illustrative agent definition examples showing how runtime components are registered and governed
- Expanded discussion of harness engineering, context engineering, and policy versioning across the full agent stack
- Product-specific implementation notes for teams that need to operationalise the vocabulary in production
👉 Read TruFoundry's mapping of AI agent terms to production infrastructure →
AI agent vocabulary: what it means for governance and stack design?
Explore further
21/08/2026 5:11 pm
Vocabulary is becoming a governance control plane. The article shows that shared AI agent terminology is not just semantic cleanup. Once model, scaffold, harness, tool, skill, and sub-agent are mapped to concrete infrastructure, governance can finally attach to each layer. That makes inventory, accountability, and control design possible in a way a loose "agent" label never does. The practitioner conclusion is simple: if the team cannot name the runtime component, it cannot govern it.
A question worth separating out:
Q: What should organisations do first when moving from chatbots to agents?
A: Start by defining the runtime boundaries before scaling the use case. Decide which tools are allowed, who approves execution, how context is managed, and what traces are retained. That sequencing matters because the main risk is not the model itself, but the permissions and automation around it.
👉 Read our full editorial: AI agent vocabulary maps to the production stack teams govern
