Most enterprise agents still wait for a person to type a question. An autonomous agent does not: it starts on a schedule or an event, works through a bounded task, and records what it did, with nobody prompting each step.
That changes what has to be designed. In a chat, a person starts the work, sees each answer and decides what to do with it. Without that person, the system itself has to settle what starts the work, whose authority the agent uses, what it may touch, what happens if it stops halfway, and how anyone knows it did the right thing.
Microsoft Foundry now manages much of this. Since September 2026, routines can start agents without a conversation, and Agent Service, Toolboxes, delegation and tracing cover running, tooling and recording them. This article explains each part, and the decisions Foundry still leaves to your team.
What Makes an Agent Autonomous
An agent is autonomous when it can begin and progress through work on its own. That is different from having broad authority. A well-designed autonomous agent runs a narrow, repeatable task, such as reviewing new records each morning or reacting to a new issue, with a short list of permitted tools and a clear point where it stops and hands over to a person.
Autonomy also does not change the basic levels of agent responsibility. An unattended agent can still only answer, recommend or act within the limits it was given. Running without a prompt makes those limits more important, because nobody reviews each step as it happens.
The Parts Foundry Provides
Foundry runs the work. Your rules decide each outcome.
An unattended agent in Foundry is assembled from four managed parts:
- A routine starts the work.
- Agent Service runs the agent, either as a prompt agent configured from instructions, a model and tools, or as a hosted agent that runs your own code inside Foundry.
- A Toolbox defines which tools the agent can call.
- Run history and traces record what happened.
One part is always yours: the application rules that decide what happens to each result, and the design that lets interrupted work resume safely. The sections below take each part in turn.
How Work Starts Without a Prompt: Routines
A routine connects a trigger to an agent. Routines are generally available and support four triggers: a recurring schedule, a one-time timer, a GitHub issue event and a supported Teams message event. Each invocation appears in the routine's run history, so a team can see whether work started before looking at what the agent did.
Routines run prompt agents and hosted agents, but not workflow agents. They do not support customer-managed-key encryption, and some regions are excluded, so check those limits before choosing them for a regulated workload. A related reminder tool, which lets a hosted agent schedule its own later continuation, is still in preview.
Whose Authority the Agent Uses
Every tool call runs under an identity, and the routine decides which one. By default it is the agent identity, the agent's own Microsoft Entra identity. A routine can instead use its creator's identity when a tool needs delegated access to that person's data. Sign-in for event connectors is configured separately.
The trigger starts the work. The routine's identity does it.
This matters most for event triggers. When a message or an issue starts a routine, its author has not delegated their rights to the agent and cannot use the message to widen what it may do. The agent still runs as the identity the routine defines, inside the scope the team granted. Foundry's runtime also enforces supported Entra and Agent 365 lifecycle changes, so disabling or deleting an agent's identity applies to scheduled work too.
What the Agent Can Reach: Toolboxes and Delegation
A Toolbox is a versioned collection of tools behind one managed endpoint, with authentication and tool descriptions configured once. Several agents can share it, and tool search lets an agent find the right tool without loading every definition into its context. Toolboxes are generally available for hosted agents and in preview for prompt agents.
The toolbox is the most direct control over what an unattended agent can do. A tool that is not in the toolbox cannot be called, however the agent's instructions are worded. Give an autonomous agent read tools for what it needs, write tools only for changes that are safe to repeat, and nothing for consequential actions it should hand to a person.
Agent-to-Agent (A2A) delegation, generally available, hands a task to another agent's endpoint. That is different from calling a tool: the other agent interprets and completes the task, so its endpoint, credentials, data handling and returned evidence need the same review as any external system.
What Happens When Long Work Is Interrupted
Unattended work runs longer and with nobody watching, so failures happen mid-task. Foundry's long-running hosted-agent resilience, in preview, can detect a lost process and re-enter a registered handler with the same work identity and input. It does not restore the code's local variables, and it does not know which external changes already happened.
Recovery restarts the handler. Checkpoints decide what it repeats.
Two design ideas close that gap. A checkpoint records which items are finished, so a restarted handler can skip them. Idempotency means repeating an operation has no extra effect: setting a field to the same value twice is harmless, while sending the same notification twice is not. Every write an autonomous agent makes should be safe to retry.
How You Know the Agent Did the Right Thing
Four records answer four different questions:
| Record | Question it answers |
|---|---|
| Run history | Did the work start on time? |
| Traces | What did the agent read, call and decide? |
| Evaluation | Does this agent version handle known cases correctly? |
| The system of record | What actually changed in the business? |
Only the last one is the outcome. A trace can show that the agent called a tool without showing that the result was right. Reliancy recommendation: check a regular sample of results against the system of record, add the cases people had to correct to the evaluation set, and release a new agent version only when it passes them. Evaluating production agents with Microsoft Foundry covers that loop.
Two newer features help but do not decide. Insights in Foundry, in preview, looks for recurring failure patterns across traces. Agent optimizer tests candidate changes against evaluation goals; a better score is a reason to review a change, not to ship it unattended. Traces can contain business data, so control who can read them and how long they are kept.
What the Platform Controls, and What It Leaves to You
Foundry adds runtime limits that reduce risk. Hosted agents can restrict their outbound network destinations, in preview, and identity lifecycle changes are enforced at runtime. None of these checks whether a result was correct or a decision was justified. That is business validation, covered in governing agents and data in the Microsoft stack.
Questions to Answer Before Running Unattended
- Owner: who is accountable for the agent's results and receives escalations?
- Trigger and scope: what starts the work, and where does the task end?
- Identity: which identity does it run as, and has it been tested as a restricted identity?
- Tools: does the toolbox hold only what the task needs, with no consequential actions?
- Recovery: are there checkpoints, and is every write safe to repeat?
- Pause: can the routine be disabled without losing its run records?
- Outcome: how will results be checked against the system of record?
Discuss a bounded autonomous-agent deployment with Reliancy.
Sources and Product Documentation
- Foundry Agent Service and agent types
- Routines in Microsoft Foundry are generally available
- Use routines: triggers, identities and limitations
- Create and manage Toolboxes
- Agent-to-Agent connections in Foundry
- Long-running hosted-agent resilience (preview)
- Hosted-agent guardrails and network egress controls
- Insights in Foundry (preview)
- Trace data and handling
- September 2026 Foundry runtime, tools and optimization announcements