Browser + computer
Use interfaces when work cannot be completed reliably through an API, subject to the configured environment and action boundaries.
Explore browser agents →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.
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.
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.
Use interfaces when work cannot be completed reliably through an API, subject to the configured environment and action boundaries.
Explore browser agents →Retrieve the context an agent is allowed to use while keeping long-lived memory and curated knowledge as distinct resources.
Explore agent memory →Expose approved functions, APIs and connected systems as explicit capabilities instead of silently assuming the model can act.
Resolve configured model candidates and fallback paths without hard-wiring every agent to one provider.
Explore model routing →Connect real-time conversation to the same knowledge, tool and policy model instead of operating a separate voice automation island.
Explore Voice Agents →Give an agent bounded access to information surfaces needed for the task, based on the configured runtime context.
A capability may exist in the product and still be unavailable for a specific run. Effective access depends on multiple layers resolving together.
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.
Exact capability reachability remains configuration- and deployment-dependent. Createting uses one canonical capability model rather than separate capability truths for each runtime consumer.
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.
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?”
A shared capability model reduces the pressure to rebuild browser, memory, tool and policy logic independently for every agent surface.
Capability availability and action authority can be resolved before external effects instead of being inferred from model confidence.
Additional agents, channels and execution environments can be designed around the existing capability contract rather than creating another isolated stack.
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.
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.
Capability Fabric is Createting's canonical model for runtime capabilities such as browser, computer, memory, knowledge, voice, files, search, tools and other execution resources.
No. Effective use can depend on agent configuration, workspace resources, scope, policy and whether the current deployment supports the capability.
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.
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.
Bring the agents, tools, channels and execution surfaces your workflow needs. Map the runtime and authority boundaries before scaling.