Autonomous agents
Give an agent a standing objective and permission to work on it unattended — policy-gated, journaled, and able to stop and ask.
An agent normally waits for you. Give it an objective and set it autonomous, and it keeps working between your messages — on its own schedule, reporting back what it did.
This is a mode on an ordinary agent, not a separate kind of agent. Same home,
same SOUL.md, same memory, same skills, same model and tool settings from the
Agents page. Two settings turn it on:
agents:
jobhunt:
objective: "Find backend roles at Series B-D startups and keep a shortlist"
autonomous: trueTwo settings, kept separate
They answer different questions, so they are separate grants:
objective— what is this agent for?autonomous— may it act on that without being asked?
Giving an agent a goal is not the same act as letting it pursue that goal unsupervised, and all four combinations are useful:
autonomous | objective | What you get |
|---|---|---|
| ✓ | ✓ | Works the objective on its own schedule. |
| ✓ | — | A recurring scheduled task that is policy-gated, journaled, and can stop to ask you something. |
| — | ✓ | A goal you work on together; it runs only when you ask. |
| — | — | An ordinary agent. |
The second row is the quiet win. A plain scheduled task has always run with
nobody watching — autonomous: true is what gives it a policy gate, an audit
trail, and somewhere to put a question, whether or not it has a standing
objective.
Because nobody is watching
An unattended run cannot ask permission halfway through, so its authority is settled in advance and everything it does is recorded.
- Approved policy. A run does consequential work only under a policy you approved, pinned by hash. No approved policy means the run stops before it starts — not partway through.
- Action journal. Consequential actions are recorded before they happen, with the policy they ran under. That journal is how you see what happened while you were away.
- Resource grants. File access is limited to paths you granted, resolved through symlinks so a link inside a granted folder cannot reach outside it. Revoking takes effect on the next run.
- It stops and asks. When it needs something only you can answer, the run suspends and the question waits for you. Answering resumes it from exactly that point — nothing already done is repeated.
- Bounded. Each wake is one bounded piece of work that ends by reporting, scheduling its next wake, or asking you something. It never runs in a loop.
Setting one up
Talk to memcode admin. Say what you want the agent to
do; it works out what that needs, shows you the whole thing in plain language —
which files, what the policy allows, whether it runs unattended, how often —
and builds it once you approve.
$ memcode admin
> I want an agent that helps me find backend jobs. My resume is at ~/resume.md.It will propose the objective, the resource grant for your resume, a policy scoped to what the work actually needs, and a schedule — then set all of it up in that one conversation. Autonomy is always confirmed on its own, never bundled in with the objective.
Real work, real capabilities
The agent's own loop is deliberately small: plan, remember, read and write granted files, ask you, report. When the objective needs more than that, it delegates to a scoped worker — a full memcode agent with browser, MCP, shell, filesystem, and skills — bounded by a subset of its own approved policy. It picks the result up on a later wake.
Your browser, not a fresh one
Most useful browser work happens inside accounts you are already signed into.
Set browser: existing_chrome and the agent drives your own running
Chrome, inheriting those sessions, instead of a blank logged-out profile:
agents:
jobhunt:
objective: "Find backend roles and keep a shortlist"
autonomous: true
browser: existing_chromeThis needs Chrome 144+ with Remote Debugging enabled at
chrome://inspect/#remote-debugging, a running gateway, and your click on
Chrome's own permission dialog — that consent is yours to give and nothing can
give it for you.
If that connection is not available, browser work fails and says so. It never quietly falls back to a logged-out browser, because doing the task signed out is not the task you asked for.
Connecting an agent to your signed-in browser is broad access by design — it inherits whatever you are logged into. Grant it to work you actually want done on your behalf, and check what happened with the run journal.
Memory
What the agent learns goes into its memory.md and comes back on every future
run, so something you answer once is not asked again.
Worth knowing the limit: that memory is prose, so it does not record how it learned something — you told it, it read it in a file, it saw it on a page. Keep that in mind before relying on an agent to state facts about you somewhere consequential.
Staying in control
- Pause stops future unattended runs without deleting anything; resume any time.
- Revoke a resource grant or a policy and the next run is bounded by the new terms.
- Removing an agent from your config keeps its home and memory. Deleting that is a separate, deliberate act.
- Ask
memcode adminfor its journal, its pending questions, or a health check at any point.
Everything lives under ~/.memcode/agents/<name>/: its memory, a readable
mirror of its policies and grants, its run history, and its workspace.