Tell an agent to build a team, schedule it, and remind you when it's done

Here is what happened last week. In a single chat session, an agent was asked to build a research workflow, add two characters to it, put it on a daily cron, and notify the team when the first run completed. The agent did all four things without touching a dashboard. It created the workflow, edited its steps, scheduled the cron, and sent the Telegram notification — all from the chat surface, in sequence, in one turn.

That is the thing we shipped. And it matters more than it sounds.

The part every agent platform skips

Every platform pitches “describe the work in plain English.” Most of them mean one thing: describe a task. You tell the agent what to do, it does it, you check the result. That’s one-shot assistance, and it’s genuinely useful.

But the harder problem is: who decides when the work happens? Who staffs the team? Who edits the team spec when requirements change? Who arranges the notification when it’s done? On almost every platform today, the answer is still: you open a dashboard, navigate to a configuration screen, and do it yourself.

The control plane — the layer that decides when agents run, what team they use, and who gets told — has stayed stubbornly manual. Until now.

What shipped

Four capability gaps closed at once, and all four are live:

Create a workflow from a conversation. An agent on a chat session can now call create_workflow and generate_workflow directly. You describe what you need, the agent assembles the spec, creates the workflow, and hands you back a handle — no UI required.

Edit the workflow steps, not just the metadata. Previously, updating a workflow from a conversation meant changing its name or description. Now an agent can add characters, change transitions, and restructure the process itself — and the workflow’s identity survives the edit unchanged. You can iterate on the team spec in the same conversation that created it.

Put it on a cron. Schedule tools — create, list, update, delete — are now reachable from chat and voice surfaces, not just from inside a running workflow. You can say “run this every morning at 07:00 UTC” and the agent creates the schedule. You can say “pause it” and the agent updates it. The schedule appears in your organisation’s schedule list, same as one you’d configured manually.

Send a reminder when something finishes. A notification tool now reaches the chat surface. Ask the agent to “ping me when the first run completes” and it queues a Telegram message for approximately that time. The notification lands in your organisation’s configured channel — not a per-person DM, which is a routing distinction worth knowing — but it arrives, reliably, once.

All four were live-tested in a single chat session on 2026-09-27.

The permission model that makes this safe

This is the part worth understanding if you’re thinking about deploying this.

The write tools — the ones that actually create, modify, or schedule workflows — are not available to every agent by default. They gate on a capability grant that you assign per agent. An agent without the grant can see the tool, attempt it, and gets a clean refusal with an explanation; the tool’s presence is not the security boundary. The check happens at the moment of the action, not at configuration time.

This means you can give one agent the ability to build and schedule workflows without giving it blanket administrative access. You can give a different agent read-only visibility into what workflows exist. The permissions are composable and checked at runtime — the same pattern enterprise security teams are investing in heavily right now for non-human identities broadly.

The practical consequence: you can let a trusted orchestrator agent manage recurring work on your behalf, knowing that a different agent talking to the same platform cannot do the same unless you’ve explicitly said so.

Why this week

The AI-dev community has been building toward this pattern visibly . The platforms getting attention right now are the ones treating agents as long-running team members — entities that schedule, coordinate, and persist — rather than task-execution tools that hand back control after each step. The gap between “the agent does the work” and “the agent manages how the work gets organised” has been the silent assumption nobody was filling.

Anthropic’s engineering team has noted that the most successful agent implementations are built from simple, composable primitives. The workflow, the schedule, and the notification are exactly that — three primitives that, combined in a conversation, produce something that would have needed a custom operations layer six months ago.

What this replaces

Before this shipped, setting up a recurring agent workflow meant: create the workflow in the UI, configure the schedule separately, wire up a notification via webhook or a custom pipeline, and remember to update all three when the spec changed. Each step required a different screen, a different mental model, and a person free to do it at that moment.

Now that loop closes in a conversation. The agent that helped you think through the workflow structure is the same agent that assembles it, schedules it, and arranges the notification. The spec lives in the platform; the conversation is just how you talked it into existence.

One honest note

The reminders land in your organisation’s Telegram channel, not a personal DM. Per-user routing is on the roadmap but is not yet shipped. If your team’s workflow is “one person monitors the channel,” that works today. If you need per-user routing, watch this space.

The trajectory here is consistent with what we’ve been building across Forge’s platform — observable, composable, operable without constant attention. Agents ask permission before spawning new work . Agents review their own calls . Now an agent can build and manage the team doing the work, out loud, from a chat window.

Try Forge — or reach out at [email protected] if you want to talk through what a conversational operations layer would look like for your team.