SDK Readiness

Use this page when you are evaluating whether Ageniti is mature enough as an SDK for building apps that agents can use.

This is not a checklist for autonomous agent orchestration. It is a checklist for an app-facing SDK that must expose product capabilities safely and predictably to external hosts.

What "ready enough" means

For Ageniti, "ready enough" does not mean:

• it owns planning loops
• it ships long-term memory
• it routes between models
• it becomes an agent runtime

It does mean:

• developers can expose one real app capability without restructuring the whole app
• hosts can discover and call that capability through standard surfaces
• operators can review the contract before release
• risky actions can be filtered, confirmed, or denied consistently
• every surface returns the same execution semantics

If those properties are strong, the SDK is doing its job.

Release Bar For An Agent-App SDK

These are the capabilities that should feel solid before you call the SDK broadly usable.

1. Stable action contract

The SDK should make app capabilities explicit and reviewable.

Minimum bar:

• typed input schema
• typed output schema
• stable action names
• side effect metadata
• visibility controls
• natural-language documentation for hosts and operators

In Ageniti, this is the role of defineAction(), action metadata, and exported manifests.

2. Shared runtime semantics

Every surface should execute through the same runtime rules.

Minimum bar:

• input validation
• output validation
• timeout handling
• retry support
• permission checks
• confirmation for risky actions
• structured logs, progress, and artifacts
• stable success and failure envelopes

Without this layer, each adapter becomes its own behavior fork.

3. Standard host surfaces

An SDK for apps that agents use needs enough surfaces to meet hosts where they already are.

Current high-value surfaces are:

• CLI for operators, scripts, and CI
• MCP for tool discovery
• HTTP for internal gateways
• OpenAI-compatible tools
• OpenAI Responses tools
• AI SDK executable tools
• JSON runner for tests and automation

The key question is not "how many surfaces exist?" but "do they all preserve the same contract?"

4. Safety defaults

If an app SDK exposes product capabilities to external callers, safety defaults matter more than feature count.

Minimum bar:

• destructive actions require confirmation by default
• private actions stay off public surfaces
• high-risk actions can be restricted to trusted surfaces
• auth hooks can reuse the host app's authorization model
• public metadata stays separate from internal metadata

This is part of product credibility, not only security.

5. Package and artifact model

The SDK should generate artifacts that downstream teams can actually install, inspect, and review.

Minimum bar:

• CLI launcher
• MCP stdio launcher
• action manifest
• surface manifest
• deterministic guide or contract docs
• bundle metadata for release review

If shipping requires custom glue every time, the SDK is still too thin.

What To Improve Next

If the core runtime and surfaces already exist, the next gains usually come from adoption quality rather than more framework breadth.

Host integration examples

The SDK should show real host-facing examples, not only primitive API snippets.

Highest-value examples:

• OpenAI Responses API host
• Vercel AI SDK route handler
• MCP desktop host setup
• internal HTTP gateway wrapper

These examples help developers answer "how do I plug this into my stack this week?"

Contract maintenance workflow

The SDK should help teams evolve app capabilities without accidental breakage.

High-value additions:

• manifest diff in CI
• compatibility notes on renamed or deprecated actions
• examples of versioned action rollout
• release review guidance for risky contract changes

Operator-facing debugging

Teams adopting an app SDK need to diagnose failures quickly.

High-value additions:

• clearer error taxonomy
• invocation replay examples
• artifact inspection guidance
• examples of logging and progress conventions
• doctor checks for common integration mistakes

Better positioning docs

Many SDKs get misunderstood because they are compared against agent frameworks.

The docs should make these distinctions obvious:

• app SDK versus agent framework
• app capability versus agent skill
• host integration versus orchestration
• product boundary versus workflow engine

When the positioning is sharp, the right users self-select faster.

A Simple Maturity Test

If a new team can do all of the following in one afternoon, the SDK is in good shape:

1. Wrap one existing product capability as an action.
2. Run it through CLI locally.
3. Expose it through MCP or tool calling.
4. Restrict one risky action from public surfaces.
5. Export a reviewable guide and manifest.
6. Understand failures without reading SDK internals.

If any of those steps still feel fragile, that points to the next documentation or product gap to fix.

Bottom Line

Ageniti does not need to grow into an agent framework to become stronger.

It becomes stronger by making app capability exposure:

• clearer to adopt
• safer by default
• easier to review
• easier to package
• easier to integrate into real hosts

That is the standard to optimize for.