Skip to main content

​
First projects

These rungs assume a seeded local instance, a logged-in CLI, and a workspace with an available model credential. Run them in order; each adds one platform capability. The example deliberately uses one crew and one agent so the boundary stays visible. In a real workspace, choose a slug that is not shared by another tutorial run and give the crew only the network, skills, and credentials this task needs.

​
1. Create a crew

The first command creates the execution boundary. The second proves the new crew is visible in the current workspace. Check: the list row should contain docs-lab. If it does not, stop here: later commands would be testing the wrong workspace or profile.

​
2. Give an agent a task

The agent is a worker inside the crew, not a second server. The file is deliberately written to shared storage so the result can be checked independently of the model’s prose. Check: hello.txt is evidence produced by the run. A natural-language “I wrote the file” response is not equivalent evidence because it does not prove the shared-volume write happened.

​
3. Hand it a credential and share memory

Use a throwaway, non-production value in a local instance:
Credential values are injected for the run and are not returned by the credential listing API. Memory is a separate, durable channel: it is useful for facts that agents should recall, not for secrets. Check: the second ask should contain BLUE-BOAT, while neither the prompt nor the reply should contain local-demo-value. If the agent asks for the value to be pasted into chat, stop and fix the binding instead.

​
4. Schedule the work as a routine

Edit the generated definition so its agent step asks Writer to update the shared file, then save it using the command above. The schedule fires the saved routine on weekdays at 09:00 UTC. A routine is the durable workflow definition; a schedule is only one trigger for it. The generated file is intentionally a scaffold. Replace its placeholder agent slug and, for a script-backed routine, deliver the referenced script into the crew before expecting a scheduled run to succeed. validate proves the DSL shape; it does not provision a container or prove that a provider can answer.

​
5. Read what happened

The Journal is the audit spine. Use the routine run view for workflow-specific results and the Journal when you need the surrounding events, actor, or timing. Check: the Journal output should include the crew’s recent create, agent, credential, or run events. A routine list only proves that the definition exists; the Journal and run history answer whether work actually happened.
The commands in this page are the contract exercised by scripts/test-harness/test-first-projects.sh. The routine definition is generated by the CLI, so the harness verifies generation and offline validation; it does not claim a model-backed scheduled run without a provider credential.