An autonomous agent example only helps if you can picture the run: what fired it, what it touched, what a person received. Four cases, from a weekday digest to a monitor that opens a fix. Kortix is the open-source AI Operating System: your agents, their skills, your company memory and every connector live in one git repo you own.
Both forms write the same cron trigger, and either one is the whole schedule.
triggers: - slug: daily-digest type: cron cron: "0 0 9 * * 1-5" timezone: Europe/Berlin prompt: Summarize yesterday's commits and open change requests.kortix triggers add daily-digest --type cron --cron "0 0 9 * * 1-5" --timezone Europe/Berlin --prompt "Summarize yesterday's commits and open change requests." --applyEach card ends in the artifact the run hands back, and every name and number inside those artifacts is made up.
Weekday digest
A cron trigger fires at 09:00 on weekdays in the project's timezone, and the agent gathers the previous day's commits and the change requests still open into one page.
| Change | Owner | State |
|---|---|---|
| checkout-web | checkout | merged |
| invoicing-api | billing | in review |
| docs-site | content | merged |
Signed lead intake
A signed POST arrives at the trigger's URL, its HMAC-SHA256 check passes, and the agent writes the lead into the CRM through a connector, tagged with the form it came from.
| Field | Value |
|---|---|
| Company | Acme |
| Source | signed webhook |
| Owner | unassigned |
| Draft reply | written |
Diff review
A new pull request in a connected app fires an event trigger, and the agent reads the diff, comments on the changed lines and holds the merge while a test fails.
Queue watch
A monitor trigger runs a command from the repository and starts a session the moment it prints a line, so a queue that backs up arrives as a change request.
Microsoft calls autonomous AI agents "systems that can independently analyze situations, make decisions, and act". Its Copilot 101 page adds that they "don't just follow preset instructions" (Microsoft). Salesforce says autonomous agents "can execute on tasks and workflows independently" (Salesforce). Both sentences are true. Neither lets you picture what an agent does at 02:40 on a Wednesday with nobody awake.
The useful question is what you would actually let run. An example earns its place when it shows three things: what fired the run, what the run could touch, and what a person found waiting at the end. Follow one case the whole way and you can check those three against your own work.
Take the review case, where nobody asks for anything. A pull request opens in a connected app, and the event trigger attached to it fires. The trigger types are "cron (a schedule slot arrives, or once at run_at), webhook (a signed POST reaches the trigger's URL), event (something happens in a connected app, such as a new pull request or a new email) and monitor (a command from your repository prints a line on stdout)." An event fire substitutes the payload's values into the prompt. The session opens already holding the pull request and its branch.
Nobody picked this up from a queue, and nobody pressed go.
"A session runs one agent in its own sandbox. The sandbox clones the repo and works on a new branch." The branch carries the session id. Everything this run changes sits on that one ref, and the default branch stays as it was.
The tools are policy, written before the run. "Rule each tool call allow, ask or block." The rule can reach the arguments a call was given. That is how a review agent gets a read on the repository, the test command and a comment on the diff, and nothing near a merge. Write the list before the first Tuesday night. At 03:00 those rules stand in for the person who would otherwise have said no.
"The agent commits, pushes the session branch, and opens a change request against the project's default branch. A person with the project.gitops.merge permission reviews the change request and merges it."
The reviewer on the other end does not read a chat summary. They read a diff, the comment on the changed line, and the test that failed. Nothing the run produced is live until that merge. A rejection costs a minute, and the default branch loses nothing, because the work never left its branch.
The permission answers the question these examples raise. An agent can open the change; a person still owns the merge.
Each of the four cards follows the same steps. Only the fire changes.
The artifacts in the four cards are invented. Acme, Globex and the counts in them describe a shape, and the repositories do not exist. Everything around them is real behaviour, linked where it appears: the trigger types, the sandbox and its branch, the change request and the merge permission, the tool policy.
Three pages go further. Running an agent with nobody watching writes a trigger from an empty project and caps how often it fires. Autonomous vs human in the loop covers the three places a person can stand in a run like these. What autonomous AI agents are takes the vendor definitions apart.
A weekday morning page that gathers the previous day's commits and the change requests still open, a signed POST that becomes a CRM lead, a diff review that comments before anyone opens the pull request, and a monitor that opens a fix. Each one starts on a trigger, with nobody present.
They read, write, run commands and open a change request inside the tools you allowed, on a schedule or an event, with nobody present. The work still arrives for review, so what a run finishes alone is the draft a person merges.
A trigger fires: a cron slot arrives, a signed POST reaches its URL, a connected app reports an event, or a monitor command prints a line. Each fire starts a session with the prompt rendered against the payload it received.
A change request against the project's default branch, which a person with the project.gitops.merge permission reviews and merges. The digest case hands back one page of state; the monitor case hands back a patch.
The setup path writes the trigger, human in the loop places the person, and the definition explains the three parts.