memcode docs
Agents

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: true

Two 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:

autonomousobjectiveWhat 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_chrome

This 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 admin for 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.

On this page