AI Agent Frameworks: Connect One API to Multiple Models

AI agent frameworks are where teams define agent behavior: goals, tools, memory, handoffs, loops, and the rules for when an agent should stop. But the model access layer is a different decision. If every agent framework is wired directly to one provider, the product inherits that provider’s pricing, rate limits, outages, model changes, and account rules.

That is why AI agent frameworks work better when the framework calls one stable model API and the model layer handles choice, routing, failover, usage visibility, and billing. ShareAI fits that layer. The agent application stays outside ShareAI, while ShareAI gives developers one API for 150+ models, marketplace signals, pay-per-token usage, and a Builder path when the agent traffic should become monetizable.

Why AI Agent Frameworks Need A Model Access Layer

An agent framework should help you define the work. It should not force every model call, tool step, and fallback decision into one hardcoded provider path.

A production agent usually has different kinds of model calls. A planner may need stronger reasoning. A classifier may need low cost and low latency. A summarizer may need a cheaper route. A customer-visible answer may need a higher quality model and a safer fallback. Treating all of those steps as one default model makes cost and reliability harder to control.

ShareAI gives the application a stable model layer. Developers can compare models, test options, and route traffic through one API instead of maintaining separate provider integrations for every framework or agent step.

The Basic Connection Pattern

Most integrations follow the same pattern:

• Keep your agent framework responsible for workflow logic, tools, and state.
• Point the framework’s model client at ShareAI’s chat completions endpoint.
• Use a ShareAI API key from your server-side environment.
• Pick the model route that fits each agent step.
• Log usage by user, workspace, feature, or agent route before launch.

This pattern is especially useful when your framework already supports an OpenAI-compatible chat model client. LangChain documents how its ChatOpenAI integration can use a configurable base URL, which is the pattern many teams use when routing through a proxy, gateway, or compatible model API: LangChain ChatOpenAI documentation.

Step 1: Prove The ShareAI Request

Before changing a framework config, make one direct server-side request. This gives you a clean baseline for credentials, model selection, and response shape.

curl -X POST "https://api.shareai.now/v1/chat/completions" \
  -H "Authorization: Bearer $SHAREAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-70b",
    "messages": [
      {
        "role": "user",
        "content": "Write a short onboarding message for a support agent."
      }
    ]
  }'

Keep the key on the server. Do not expose it in browser code, public repositories, client-side plugins, or shared agent templates. When the request succeeds, move the same endpoint and key into the framework configuration.

Step 2: Point The Framework At ShareAI

For code-first frameworks, the pattern is usually a base URL, an API key, and a model name. In LangChain, that can look like this:

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
  model="llama-3.1-70b",
  api_key=os.environ["SHAREAI_API_KEY"],
  base_url="https://api.shareai.now/v1"
)

response = llm.invoke("Summarize this ticket in one sentence.")
print(response.content)

For tools that use environment variables, set the framework’s model API variables to the ShareAI key and base URL in the deployment environment, then restart the worker or agent runtime.

SHAREAI_API_KEY="your-server-side-key"
OPENAI_API_KEY="$SHAREAI_API_KEY"
OPENAI_BASE_URL="https://api.shareai.now/v1"
OPENAI_MODEL="llama-3.1-70b"

For visual tools, look for model provider settings or custom provider settings. Dify’s documentation, for example, separates system providers from custom providers in its model-provider setup: Dify model provider documentation. The exact labels differ by product, but the practical inputs are usually the same: key, endpoint, model, and usage scope.

Step 3: Split Agent Routes By Task

Once the framework can call ShareAI, avoid sending every step to the same model by habit. A better setup assigns model routes by job type.

• Planning route: use a stronger model for decomposition, tool choice, and long reasoning.
• Fast route: use a lower-cost model for classification, rewriting, extraction, or formatting.
• Customer-visible route: use the model that best balances quality, latency, and reliability for the final answer.
• Fallback route: choose a backup model that can complete the same task when the preferred route degrades.

This is where a one-API approach becomes useful. The framework does not need a separate integration for every provider decision. The application can keep a stable call pattern while the team changes routes as price, latency, availability, or quality changes.

If you are already running multiple agents, treat this as part of your operating model, not only a code setting. The broader AI agent fleet operations guide explains how routing, pricing, and ownership fit once one agent becomes many.

Where Builder Monetization Fits

Some agent workflows are internal cost centers. Others are customer-facing product features. If a Builder owns an app, plugin, workflow, chatbot, or agent product outside ShareAI, that agent traffic can become part of a usage-based business model.

The Builder still builds and owns the application outside ShareAI. ShareAI handles the routed AI inference usage, customer payment for that routed usage, margin or surcharge configuration, and monthly Builder payout based on generated earnings.

That matters for agent frameworks because agents can create uneven usage. One customer may run a few support summaries per month. Another may run thousands of research, triage, and workflow calls. With ShareAI Builder monetization, the Builder can route the AI traffic through ShareAI, set a margin, and let usage-heavy customers pay for the inference they generate.

When you are ready to map the commercial side, open the Builder Console. For implementation planning, keep the ShareAI documentation nearby.

Production Checklist For AI Agent Frameworks

• Keep ShareAI API keys server-side.
• Name each agent route before launch.
• Track usage by customer, workspace, feature, or agent.
• Separate high-reasoning routes from low-cost utility routes.
• Test the framework with at least one backup model path.
• Log model, latency, token usage, error reason, and final route.
• Avoid putting provider keys inside prompts or exported agent templates.
• Decide which agent steps are customer-billable before traffic grows.

The smallest useful rollout is one agent, one route, one backup, and one usage label. Once that path is measurable, expand the pattern to the next agent step.

FAQ

What are AI agent frameworks?

AI agent frameworks help developers define agent behavior, tools, memory, workflows, state, and execution loops. They are different from the model access layer that decides which model serves each request.

Why connect AI agent frameworks to one API?

One API keeps model access easier to change. Teams can route different agent steps to different models, compare marketplace signals, and reduce dependency on one provider integration.

Is ShareAI an AI agent framework?

No. ShareAI is an AI marketplace and API. It does not build the agent application. It can sit behind an agent framework as the model access, routing, usage, billing, and monetization layer.

Can I use ShareAI with LangChain?

Yes, when the LangChain integration is configured to call ShareAI’s chat completions endpoint with a ShareAI API key and a supported model name. Test the direct API request before wiring it into the full chain.

Can visual agent builders use this pattern?

Often, yes. If the visual tool supports a custom model provider or OpenAI-compatible endpoint, the setup usually comes down to endpoint, API key, model name, and where the tool stores provider credentials.

How should I choose models for different agent steps?

Start with the job. Use stronger models for planning and high-value responses, lower-cost models for simple classification or formatting, and backup routes for steps that cannot fail silently.

How does failover help AI agents?

Failover gives an agent another model path when the preferred route is unavailable, slow, too expensive, or unsuitable for a request. It is most useful when tested before production traffic grows.

Can Builders monetize agent framework usage?

Yes, when the Builder owns the app, workflow, plugin, chatbot, or agent product outside ShareAI and routes its AI inference traffic through ShareAI. The Builder can set a margin or surcharge for that traffic.

Who pays for routed agent usage?

In the Builder model, the customer, workspace, user, or account that generates routed AI usage pays ShareAI for that usage. ShareAI pays the Builder monthly based on generated earnings from the configured margin or surcharge.

Do Providers and Builders earn the same way?

No. Builders earn from application traffic they route through ShareAI. Providers earn through approved provider programs by contributing eligible compute capacity to the ShareAI network.

What should I track before launch?

Track agent name, user or workspace, model route, latency, token usage, error rate, fallback events, and the feature or customer action that triggered the call. That data makes pricing and routing decisions much easier later.