Product guide · Browse & search
How Core fits together
From a model connection to an agent, a workflow, and the run that does the work.
An agent is a reusable definition of work. A run is one attempt to do that work with particular input. A workflow is a process you define around agents, tools, decisions, and people. These three ideas explain most of the platform.
Where things live
| Concept | What it does | How it connects |
|---|---|---|
| Organization | Holds the organization and its memberships. | Contains projects; a membership may cover the organization or a narrower scope. |
| Project | Groups a product or body of work. | Contains environments. |
| Environment | Defines the context in which you configure and run work. | Holds the relevant connections, policies, grants, collections, and published bindings. |
| Connection | Describes an approved route to a model or integration. | Supplies a model profile, credential, or configuration that work can use. |
Development and production can use the same portable agent design while binding it to different resources. A model profile or collection in one environment does not automatically become available in another.
What you build
| Concept | What it does | Example |
|---|---|---|
| Agent | Uses a model to pursue an objective within its instructions, capabilities, and limits. | Read a customer request and draft a response. |
| Tool | Performs a defined action with input and output contracts. | Look up an order or create a ticket. |
| Skill | Supplies reusable instructions and a description of when to use them. | Follow the support triage procedure. |
| Subagent | A published specialist another agent can delegate to. | Review the draft for clarity. |
| Knowledge collection | Holds searchable reference material. | Product documentation and support policies. |
| Workspace files | Hold files produced or used in the course of a run. | A draft response or report. |
| Workflow | Defines an explicit graph of steps and the paths between them. | Draft, review, then return an approved response. |
A model supplies reasoning and generation. A skill supplies guidance. A tool supplies an action. Attaching one does not replace the others or grant permission to everything it could mention.
From definition to execution
- Draft: edit an agent or workflow without changing the version people currently run.
- Publish: create an immutable version and resolve its environment bindings.
- Start: choose that published version and provide valid input.
- Run: Core records the work, its requests, and its outcome.
- Continue or automate: a conversation can add another turn; a schedule or trigger can start future work.
An agent family is the identity that groups its draft and versions. A version is the exact published definition. A run names a published version; editing a draft does not rewrite an existing run.
Agents, plans, and workflows
Use an agent when the model should choose how to achieve an objective. Give it a plan when you want a visible list of intended work and progress. Use a workflow when you want to define the order and the possible paths yourself.
A plan is not an executable workflow graph. A plan item can report that research is complete, but it does not create a tool permission or a required approval step. A workflow can require a person to approve a specific proposal before the process continues.
What controls execution
- Memberships and grants decide who can start work and use its dependencies.
- Execution policy determines which capabilities the environment permits.
- Acceptance criteria check whether the agent's result meets its declared requirements.
- Limits bound how much work or time a run can use.
- Queues coordinate runs competing for the same key, such as one customer or document.
- Schedules and triggers decide when new runs are submitted.
- Waits and approvals let an existing run stop for a person, event, or decision.
See Access, Queues, and Schedules and triggers for the setup of each control.
One complete example
A schedule starts a published workflow with a customer identifier. The workflow passes it to a published agent. The agent uses its model profile, looks up the customer through a tool, and searches a knowledge collection. It returns structured data containing a draft response. An Approval step presents that response to a reviewer. The approved path can call a sending tool; the rejected path can finish without sending anything.
The workflow run records the process. Its agent step has its own execution. The sending tool, model profile, knowledge collection, and reviewer each have their own access requirements. Publishing the graph does not bypass those checks.