Skip to main content

Projects and steps

The word "step" may bring to mind a stage that work flows through in order. A step in a project is not that.

This page explains what a step is, what a playbook and a skill are and what they belong to, and how a project's memory is handled. For how to configure them, see the Design Guide.

A project is the unit that holds how one kind of work is carried out​

A project is the unit that holds one kind of work and how it gets carried out. You lay out steps inside it, and on the steps where you want work done, you place an agent.

Steps and agents are not all it gathers. How much to delegate, who takes part, and which connectors to use are all decided at the level of the project. The records accumulate per project too.

So creating one project means settling on one way of running the work.

A step is where you place an agent​

A step is where you place an agent. The step itself does nothing. The agent placed on it does the work, following its own goal (instructions).

And the order in which you lay out the steps is not necessarily the order the work runs in. A workflow does advance through them in order. In a cycle, you enable the sweep for each agent placed on a step, and each one then runs on its own schedule. Which of the two you get is decided by the type.

Agents and steps are not one to one​

An agent is not part of a step. It is a configuration of its own, so you can place the same agent on several steps, and use it in several projects.

Each single agent placed on a step is called a placement. Both the run and the sweep schedule work at this level. Place the same agent on two steps and you have two placements, and in a cycle you can give each step a different schedule.

In a workflow, placing the same agent on consecutive steps still runs it on each step. Say you place the same agent, and only that agent, on step 1 and step 2: it runs once on step 1 and once on step 2, and on step 2, as on any other step, it receives the output of step 1 together with the files produced and saved in the Library.

The other way round, you can also place several agents on one step.

What happens when several agents share a step​

In a workflow, the agents on the same step run one at a time, in placement order, and the run moves to the next step once they have all finished. Set the step to “Run at the same time” and the agents placed there run together; again, the run moves to the next step once they have all finished. Either way, agents on the same step do not pass their output to each other. What the agents on the next step receive is the output of every agent on the previous step, together with the files each of them produced and saved in the Library. The exchanges up to that point are not handed over.

A cycle has no waiting. Placements on the same step run on their own schedules too.

A step where a person decides holds no agent​

A review step holds no agent.

On a review step, a reviewer looks at what is up for review and chooses one of three: advance to the next step, send it back, or reject it. It is not a step where an agent does something; it is a step for deciding.

Where to put review steps, and how reviewers are chosen, is covered in the Review Guide.

A playbook is the procedure, a skill is the method​

The two sit in similar places, but they are different things.

A playbook is the procedure for work you repeat. Set out each step with its purpose, guidance and success criteria, and the agent works through them. An agent can have at most one, and it can have none at all.

Note, though, that the steps you write are not simply repeated. The agent adjusts them to suit the request. A playbook sets out a procedure; it is not a mechanism for reproducing the same steps every time.

A skill is the method for one particular piece of work. You register a document describing the method, together with scripts or other files if it needs them, and attach it to an agent. Unlike a playbook, an agent can have several. Which of them it uses is something the agent decides while it runs. A skill has versions. Your own skill can be changed under “Edit contents” and saved with “Save as new version” (Markdown, JSON and YAML files can be edited; a skill that contains code such as scripts is downloaded, changed and replaced). For each skill, an agent can “Follow the latest version” or use a set version.

Skills affect how an agent behaves. In a cycle, what the agent finds to work on is settled by its goal (instructions), its skills and its connectors.

Playbooks and skills belong to the agent​

Playbooks and skills do not belong to the project, and they do not belong to the step. They belong to the agent. The same goes for the goal (instructions) and the guardrails: the agent holds them. The sweep schedule, on the other hand, belongs to the placement rather than the agent.

This ownership has consequences later on. Change an agent, and from the next time it starts it runs with what you changed. This is the same in a workflow and in a cycle. So if you also use the same agent in another project, what you change in that agent reaches those other projects from their next run onwards. A small change meant for one project changes how the others behave too.

If you want different behaviour per project, use separate agents.

Project memory is never rewritten​

A project has memory. After each run, decisions and the conditions it got stuck on are selected and kept, if they would help a later run. Only what is selected is kept — not everything that came to light during the run. A later run is given only the memory relevant to what it is doing.

This memory is never rewritten. When something wrong has got in, the platform retires that entry and adds a new one. The old entry is not deleted; it is only marked as retired. You cannot pick out a memory and delete it yourself.

There is one more thing. What a person decided cannot be retired by an agent. A decision made on a review step can only be replaced by a later decision made by a person.

There is no screen for viewing or editing the memory.

Apart from the project memory, “Company memory” can be read too. Company-wide memory is always read; organization and job role memory is read only where chosen for an agent in the project (up to one organization and one job role). If the same agent is placed on several steps, there is one setting for all of them. What can be chosen is the organizations and job roles of the current members; a choice that later falls outside them stays in the setting but is not read. A project's runs do not read anyone's personal memory, including the creator's. Nor do they use past chats outside the project, or write into company memory.

  • Cycle and workflow — the type where the order of steps matters, and the one where it does not
  • Design Guide — adding steps, reordering them, placing agents
  • Review Guide — where to put review steps, and who decides