In most real-world systems, “AI agents” sit on top of a polyglot stack:
- Python for data and ML
- TypeScript/Node for backend and APIs
- Rust/Go for performance-sensitive pieces
If your capability model only really exists in one language, you end up with:
- Duplicate logic in other languages
- Inconsistent validation and error handling
- Governance rules that only apply to the Python part
A more sustainable pattern is to treat the capability protocol as the primary artifact and the language SDKs as implementations.
Concretely:
- Specify a wire-level protocol and schema format.
- Define how metadata (risk, cost, ownership) and governance hooks (ACL, approvals, audit) attach to a capability.
- Build SDKs in your target languages that:
- Use the same conformance tests
- Expose idiomatic APIs
- Produce identical runtime behavior
Now a capability implemented in Rust can be:
- Called by a Python-based agent
- Exposed as an HTTP endpoint by a TypeScript service
- Invoked via CLI by ops teams
…without reinventing validation, approvals, or tracing.
If you are designing your own internal runtime, consider starting with the protocol and tests first, and only then layering language-specific ergonomics on top. It is slower upfront but pays off when your stack inevitably becomes polyglot.