How is this different from a cron job?

Cron runs a fixed command. Your Fasrad autonomous agent runs a full LLM turn with tool access — it reads current state, decides what to do, and handles changes (the list grew, the API format shifted, the recipient changed).

Can it really send emails / update sheets autonomously?

Yes. On each fire, the agent has all tools enabled (subject to your permissions). You can configure whether it sends directly or drafts for approval, per tool.

What about mistakes? Can I review what it did?

Every Task fire is logged in your /tasks page with inputs, tool calls, outputs, and timestamps. Audit trail is permanent.

How do event triggers work?

Three events today: new_email (mail arrives in your agent's inbox), new_public_message (someone writes in your public agent chat), lead_captured (your public agent saves a lead). You attach a prompt + max_frequency (every_time / once_per_hour / once_per_day).

What if a Task goes wrong?

A circuit breaker blocks new retries when the last 2 of 3 similar tasks hit the same external error. Rate limits (20/hour one-shots, 15 pending max) prevent runaway. You can cancel any Task from the /tasks page.

Can I pause all Tasks at once?

Yes. Disable the agent and every scheduled Task pauses. Re-enable to resume. Individual Tasks can be cancelled without affecting the rest.

How is this different from Developer Agent or Incident Responder?

Those are specializations. Developer Agent emphasizes script execution + API discovery. Incident Responder emphasizes alert-driven runbooks. Autonomous Agent is the underlying scheduling + autonomy primitive they all build on — generic enough for any repeatable task.

AI Autonomous Agent that runs real work on schedule

Describe what should happen and when. Your agent runs full autonomous turns with tool access on the cadence you set — cron, recurring interval, or event triggers like new_email and new_public_message.

Your AI autonomous agent — scheduled autonomy, not reminders

Most "schedulers" send reminders. Fasrad schedules real agent turns. When a task fires, your agent gets a full LLM turn with every tool enabled — it can browse the web, email your clients, update a spreadsheet, call an API, run a script, and write the results back. Not a notification that you should do something. The work, done.

Schedule with plain language: *“every Monday at 9am, re-check the top 5 competitor pricing pages and email me the diff.”* That becomes a cron-based Task. *“Tomorrow at 8am, check if the inbound from Acme got a response yet and chase if not.”* That becomes a one-shot Task with a smart follow-up. *“Whenever a new lead captures, enrich them from the web and add to the CRM.”* That becomes an event trigger.

Strongest benefits:

Real autonomous turns — every fire is a full LLM call with all tools, not just a template.
Four scheduling modes — absolute time (`at`), delay (`in 2h`), recurring (`every 1d`), or cron (`*/5 * * * *`).
Event triggers — fire on `new_email`, `new_public_message`, or `lead_captured` — with dedup throttling.
Smart follow-ups — if the topic was already resolved in conversation, the follow-up silently skips (embedding-based staleness check).
Guardrails against runaway loops — rate limits, backlog cap, dedup on recurring, circuit breaker on repeated env failures.

Compared to Zapier / Make, Fasrad is conversational. You describe what should happen in a chat; your agent writes and schedules the logic. No per-integration setup, no visual workflow builder — just plain English and a cadence. The agent has all your tools (email, calendar, sheets, browse, HTTP) available on every fire.

Compared to a cron job + script, Fasrad is adaptive. Cron runs the same commands regardless of context. Your autonomous agent reads the current state (your calendar, your email, last week's data), decides what to do, and runs it — with human checkpoints where you configure them.

Guardrails in the code keep things sane: 20 one-shots per hour per agent, 15 pending tasks max, duplicate recurring tasks rejected, and a circuit breaker that blocks new retries when the last 2 of 3 similar tasks hit the same external error. Failure modes stay contained.