Build your first agent

Start with something you want done. Choose the model and tools that fit the task, define what your agent may access, and check the result before giving it more responsibility.

This guide brings those decisions together around a small first outcome: an inventory of one Google Drive folder, with file names, types, and links. You can follow the linked setup guide to run it, then build on the result.

In OutcomeCI, a workflow is the definition of your agent’s work. It names the trigger, reasoning runner, connected APIs, instructions, and permissions. You will see that term in the dashboard, YAML files, and CLI commands as you build your agent.

1. Define an outcome you can check

Write down what a successful result looks like before choosing tools. For the folder inventory, that means:

List the files directly inside one folder.
Include each file’s name, type, and link.
Say when the folder is empty or the inventory is incomplete.
Leave files unchanged.

Use a test folder with a few files you recognize. You will compare the agent’s output with those files after its first run.

For a different first task, you could bring your agent into Slack to answer messages, or follow the local quickstart to read a GitHub repository and propose a change.

2. Choose how you want to build

You can write the workflow yourself or build it with an MCP client connected to OutcomeCI. The MCP server URL is:

https://api.outcomeci.com/v1/mcp

Follow the setup guide for your client:

Once connected to your workspace, give it a concrete request:

Help me build a Google Drive inventory agent in OutcomeCI. It should list the files directly inside one folder and return their names, types, and links. Help me choose a supported runner and model. Only grant folder listing access; it should not download or change files. Report an empty folder or an incomplete inventory explicitly. Show me the workflow and permissions before publishing it, then help me run it and inspect the result.

The Google Drive guide contains the complete example YAML and setup steps if you prefer to edit the file directly.

3. Choose what powers your agent

The client helping you build and the runner executing your agent’s work are separate choices. Connecting an MCP client does not also connect a cloud runner account.

For cloud execution, choose a runner and model supported by your workspace. These guides explain the account connections for two options:

Your workflow’s reasoning field records that choice. The Drive example uses Claude; change it to match the runner and model you have connected. The reasoning reference explains the available configuration and fallbacks.

4. Connect the tool and define its access

Follow Give your agent access to Google Drive to choose a folder, create the workflow, and authorize Google through the Vault. Signing into OutcomeCI with Google does not grant access to Drive.

There are two access decisions to review. The Vault connection must be granted to the workflow, and the step’s can list must permit the operation. In this example, the step may call drive.files.list for the folder you selected. It has no grant to download or change files.

Google’s consent grants a broader read scope to the account; the folder restriction is enforced by OutcomeCI. Review both when connecting the tool.

For other services, browse the connector catalog. Store credentials through the Vault; if you keep them in 1Password, link them through your workspace’s service account.

5. Run it and inspect the outcome

Use the Drive guide’s run instructions to complete any required policy review, enable the webhook, and start a run. Keep the webhook URL private. Open the resulting invocation in the dashboard and inspect the inventory output under Artifacts.

Check the result against your original definition of success:

Do the names, types, and links match the files in your test folder?
Did the run call drive.files.list for the intended folder?
Does it clearly report an empty folder or incomplete listing?
Were any calls refused or steps unsuccessful?

A completed run is a starting point for review. The actual output and call records tell you whether it achieved the outcome. See what a run records for the evidence available to inspect.

6. Give it the next useful capability

Once the inventory is correct, decide what would make it more useful. You could add document reads to summarize the files, connect Slack to share the result, or choose another supported model and compare its output on the same task.

Make one change at a time. Review the updated instructions and permissions, then run the same test again. When you add actions that change external systems, decide where human approval belongs before enabling them.

Your first agent now has a defined purpose, a reasoning engine, a connected tool, and a result you can inspect. Build the next capability around the next outcome you want.