How does AutoGen think about the boundary between prototyping environments and production systems?

[Tanishq (Tanishq1030)]

I've been studying several agent frameworks recently and noticed that AutoGen has a particularly rich ecosystem around experimentation, including AutoGen Studio, agbench, evaluation tooling, and orchestration libraries.

One thing I'm curious about is where the project intentionally draws the line between prototyping and production concerns.

For example:

• Should developer-facing tools be expected to provide production-grade containment and execution controls?
• Is the expectation that host containers, VMs, and infrastructure handle those responsibilities?
• How does the team think about the transition path from experimentation to production deployment?
• Are there architectural principles that determine which capabilities belong in the framework itself versus downstream infrastructure?

I'm interested in understanding the design philosophy here, especially since many users encounter AutoGen first through Studio and benchmarking environments before moving toward production systems.

Would love to hear how maintainers and practitioners think about these tradeoffs.

[Michael 'Mike' K. Saleme (msaleme)]

Great question -- this boundary is where most agent projects quietly accumulate production debt.

In our experience testing agent frameworks for security and accountability, the cleanest distinction is:

Prototyping concerns belong in the framework: rapid orchestration, easy tool registration, visible state, friendly debugging. AutoGen Studio and agbench are excellent at this.

Production concerns should be hookable by the framework but owned by downstream infrastructure: execution containment, audit trails, cryptographic attestation, scope enforcement, and verifiable logging. The framework shouldn't try to be a container runtime or a certificate authority, but it should expose well-defined extension points so production operators can plug those in without forking.

Where this gets tricky is the middle layer: things like retry policy, timeout handling, and error propagation. Those feel like "framework conveniences" in a prototype but become "operational policy" in production. Our view is that the framework should ship sensible defaults but expose them as overridable policy, not hardcoded behavior.

For AutoGen specifically, the most valuable production hook would likely be a pre/post execution interceptor around execute_function that lets operators emit attestations, enforce scope limits, or route calls through an external policy engine without modifying the core framework. That keeps Studio uncluttered for experimenters while giving production teams a clean integration path.

The transition path you asked about is the hard part. Most teams don't realize they need auditability and scope enforcement until something goes wrong in production. By then, the framework code is deeply entangled with business logic. Designing the hook early -- even if most users ignore it initially -- prevents that entanglement later.

https://github.com/msaleme/red-team-blue-team-agent-fabric

[Tanishq (Tanishq1030)]

Thanks for the thoughtful response Michael 'Mike' K. Saleme (@msaleme) -- really appreciate the nuance around the prototyping vs production boundary.
I especially liked your point about keeping the framework focused on clean extension points rather than owning the full production stack. That makes a lot of sense.

Out of curiosity, I took a look at the red-team-blue-team fabric you linked (and ran a static governance scan on the broader AutoGen codebase). It highlighted several areas that feel exactly like the “production debt” you mentioned things like unsandboxed subprocess calls in agent tools, missing runtime policy enforcement, and unencrypted vector store operations.
I’ve been building a prototype governance layer (focused on cryptographic decision logging, policy binding, and reconstruction) and have tested it against AutoGen, LangGraph, OpenHands, and a few others. It’s still early, but it’s interesting how consistently these gaps appear once you move beyond experimentation.

Do you think frameworks like AutoGen should provide stronger first-class hooks for this kind of verifiable auditing and containment? Or is the expectation that teams will always bring their own governance middleware?
Would love to hear your take.