Framework as specialist
A custom graph or agent service can remain behind the scenes while General Augment governs how the product assistant invokes it.
Category comparison
Agent frameworks vs a managed agent backend
Agent frameworks are strong building blocks for teams that want to assemble and operate their own agent stack. General Augment is for teams that want a governed backend around an existing app, with API calls, memory, tools, approvals, channels, usage, and observability in one product surface.
Use agent frameworks when
- Your team wants to build and own the full agent stack.
- The project requires a bespoke research or automation architecture.
- You have the engineering time to operate memory, tools, traces, approvals, and deployment.
Use General Augment when
- You want an app-agent backend instead of a custom platform project.
- You need repeatable setup for product teams, agencies, or multiple apps.
- You want the first path to be one server-side API call, then tools and memory.
Decision table
Compare the layer, not just the feature list.
Decision area
agent frameworks
General Augment
Ownership
Frameworks give engineers building blocks for loops, graphs, tools, and custom orchestration.
General Augment gives product teams a managed app-agent backend with projects, keys, memory, tools, channels, and traces.
Operations
Your team owns runtime deployment, state, observability, approvals, evals, billing evidence, and support workflows.
The platform owns the repeated production surfaces around each app-agent turn.
Adoption path
A framework usually starts as code in your agent service.
General Augment starts with one backend API call and expands into governed tools, memory, channels, and private capacity.
Architecture fit
Where the categories fit together.
Agent frameworks are development building blocks. General Augment is the product backend that app teams integrate with and operate through.
Incremental adoption path
1. Call POST /v1/responses from your backend
2. Send a stable app user id
3. Add memory when durable facts matter
4. Connect app APIs as governed tools
5. Review usage, traces, and approvalsMigration path
Start where you are. Add the agent backend when the product needs it.
- 01Use frameworks for bespoke agent behavior, research flows, or internal automation services.
- 02Put customer-facing product-agent turns behind General Augment when app users, memory, approvals, and traces matter.
- 03Keep framework-built specialist services as connector or tool backends when they remain useful.
- 04Expose only narrow governed actions from those services to the product agent.
Specific examples
SaaS assistant
The app sends user id, product context, and allowed tools to General Augment rather than building a separate agent platform.
Agency repeatability
Each client gets a separate project, keys, memory, tools, and usage evidence without rebuilding orchestration from scratch.
When not to use General Augment
Use the smaller tool when the smaller tool is enough.
Use a framework when the agent architecture itself is the product.
Use a framework when your team wants to own graph logic, persistence, evals, deployment, and observability directly.
Use a framework when the workflow is not embedded in an existing app or product surface.
FAQ
Does General Augment replace agent frameworks?
No. Frameworks are useful for custom agent systems. General Augment is the product backend layer when an existing app needs governed agent behavior without building every production surface.
Can a framework-built service connect to General Augment?
Yes. A framework service can sit behind a connector or governed tool, while General Augment handles app identity, approvals, traces, memory, and user-facing product integration.
When should I choose an agent framework first?
Choose a framework first when you need a bespoke agent architecture and have the engineering capacity to operate the surrounding runtime, state, observability, and governance.