AI AGENT RUNTIME · CAPABILITY FABRIC

One runtime for every capability your agents can use.

Browser, computer use, memory, knowledge, tools, models, voice, search and files can be configured as explicit runtime capabilities. The runtime resolves what is actually available and governed for the current agent and environment—instead of treating a prompt as permission.

ONE CAPABILITY MODELAUTHORIZED PROJECTIONSRUNTIME RESOLUTION
CAPABILITY FABRIC
AGENTRUNTIMEeffective capabilities
BROWSERMEMORYVOICETOOLSKNOWLEDGEMODELSFILESSEARCH
CONFIGenabled for this agent
POLICYallowed in this context
ENVIRONMENTavailable here
01 · DEFINITION

What is an AI agent runtime?

An AI agent runtime is the execution layer that turns an agent configuration into actual, bounded behavior. It determines which capabilities, resources and execution paths are available when the agent runs.

The model can propose an action. The runtime decides whether the required capability exists in this deployment, whether the current agent may reach it, and which policy must be applied before execution.

02 · CAPABILITY FABRIC

Capabilities are system resources—not magic words in a prompt.

Createting's capability model gives execution surfaces a canonical place in the runtime so agents do not each invent their own browser, memory, tool or voice integration.

EXECUTION

Browser + computer

Use interfaces when work cannot be completed reliably through an API, subject to the configured environment and action boundaries.

Explore browser agents →
CONTEXT

Memory + knowledge

Retrieve the context an agent is allowed to use while keeping long-lived memory and curated knowledge as distinct resources.

Explore agent memory →
ACTION

Tools + connectors

Expose approved functions, APIs and connected systems as explicit capabilities instead of silently assuming the model can act.

MODEL LAYER

Models + routing

Resolve configured model candidates and fallback paths without hard-wiring every agent to one provider.

Explore model routing →
CHANNEL

Voice

Connect real-time conversation to the same knowledge, tool and policy model instead of operating a separate voice automation island.

Explore Voice Agents →
WORKSPACE

Files + search

Give an agent bounded access to information surfaces needed for the task, based on the configured runtime context.

03 · EFFECTIVE CAPABILITY

Configured does not always mean available.

A capability may exist in the product and still be unavailable for a specific run. Effective access depends on multiple layers resolving together.

AGENT CONFIGURATIONrequested capabilities
×
WORKSPACE CONFIGURATIONavailable resources
×
POLICY + SCOPEauthorized reachability
×
RUNTIME ENVIRONMENTdeployment support
EFFECTIVE CAPABILITYwhat the agent can actually use now
04 · ONE TRUTH

The goal is not five agent stacks with five different permission models.

Createting is designed to project authorized capabilities from one canonical fabric into the execution contexts that need them. That reduces duplicated integration logic and avoids parallel truths about what different agent surfaces can do.

SYSTEM AGENTSauthorized projection
CUSTOM AGENTSauthorized projection
SUBAGENTSbounded delegation
PATHWAYSdeterministic execution
THINKWAYSbounded reasoning
AUTOMATIONSscheduled execution

Exact capability reachability remains configuration- and deployment-dependent. Createting uses one canonical capability model rather than separate capability truths for each runtime consumer.

05 · RUNTIME VS PROMPT

Prompts describe intent. The runtime controls what can actually happen.

A system prompt can tell an agent to “use the browser,” “remember this,” or “send the update.” That instruction does not create a browser session, establish memory scope or grant an external write permission.

Those are runtime concerns. The execution layer must resolve the resource, confirm the capability is reachable and apply the appropriate authority boundary before the effect occurs.

06 · AUTHORITY

Availability and permission are separate questions.

A capability can be technically reachable while a particular action remains restricted. Createting separates the question “can this runtime do it?” from “may this agent do it now?”

AVAILABLE?Capability exists in this runtime environmentYES / NO
IN SCOPE?The agent can reach the configured resourceYES / NO
AUTHORIZED?The requested action satisfies policyALLOW / ASK / DENY
07 · WHY IT MATTERS

Add a capability once. Govern it as part of the system.

CONSISTENCY

Fewer parallel implementations

A shared capability model reduces the pressure to rebuild browser, memory, tool and policy logic independently for every agent surface.

CONTROL

Explicit execution boundaries

Capability availability and action authority can be resolved before external effects instead of being inferred from model confidence.

EXTENSIBILITY

New surfaces can join the same model

Additional agents, channels and execution environments can be designed around the existing capability contract rather than creating another isolated stack.

08 · FAQ

AI agent runtime, in concrete terms.

What is an AI agent runtime?

It is the execution layer that turns an agent configuration into actual behavior by resolving available models, tools, context, execution surfaces and policy for a run.

How is an agent runtime different from an agent framework?

A framework helps developers construct agent logic. A runtime is concerned with executing configured agents in a concrete environment, including resource availability, capability reachability and action boundaries.

What is the Capability Fabric?

Capability Fabric is Createting's canonical model for runtime capabilities such as browser, computer, memory, knowledge, voice, files, search, tools and other execution resources.

Does enabling a capability mean an agent can always use it?

No. Effective use can depend on agent configuration, workspace resources, scope, policy and whether the current deployment supports the capability.

Why should permissions live outside the prompt?

A prompt is model input, not an enforcement boundary. External effects need runtime controls that can resolve availability and authority independently from what the model says it intends to do.

Can the same capability model serve custom agents and subagents?

Yes. Createting projects authorized capabilities from one canonical Capability Fabric into the relevant execution context rather than maintaining separate capability truths for custom agents, subagents, Pathways, Thinkways and automations.

ARCHITECTURE REVIEW

Design one capability model before every agent becomes its own software stack.

Bring the agents, tools, channels and execution surfaces your workflow needs. Map the runtime and authority boundaries before scaling.

Request an architecture review →