docs: add Proactive agents page (cron + integration + combined)#952
Conversation
…ned) Covers the three listener kinds (clock / radio / inbox) and the persona.json + agent.ts shape for each pattern. Includes the source scope discriminator (deployer_user / workspace / workspace_service_account) and the deploy + memory bits a first-time author needs. Filed under Advanced, alongside Workforce and Cloud. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR adds comprehensive documentation for proactive agents—personas with automated listeners (clock/cron, integrations, inbox)—and integrates it into the docs navigation system with a Zap icon. ChangesProactive agents documentation and navigation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
web/content/docs/proactive-agents.mdxParsing error: Expression expected. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Preview deployed!
This preview will be cleaned up when the PR is merged or closed. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
web/content/docs/proactive-agents.mdx (1)
197-203: ⚡ Quick winConsider explaining
ttlDaysbefore showing it.Line 203 introduces
ttlDays: 60in the memory configuration example without prior explanation. While the field name is somewhat self-documenting, a brief note about memory retention/expiration would help readers understand when and why to configure it.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/content/docs/proactive-agents.mdx` around lines 197 - 203, Add a short explanatory sentence about ttlDays immediately before the example so readers know it controls memory retention/expiration (e.g., how long saved memories persist and are eligible for recall), then present the JSON snippet with "memory": { "enabled": true, "scopes": ["workspace"], "ttlDays": 60 }; reference the memory.enabled, memory.scopes, and ttlDays fields so the reader can connect the description to the example.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@web/content/docs/proactive-agents.mdx`:
- Around line 37-72: Clarify the "cron-based" vs "cron-only" terminology: update
the "Cron-based (clock listener)" section and the sentence that currently reads
"Cron-only personas get all integration fields as `undefined`" to explain that
integrations declared under the persona (the integrations object and entries in
schedules[]) serve two roles—(1) defining triggers (what events the persona
receives) and (2) making runtime clients available on ctx (e.g., ctx.slack!,
ctx.github). Explicitly state that a persona with schedules but with
integrations declared (as in the example using schedules and "integrations": {
github, slack }) will receive only cron events while still having client access,
whereas a true "cron-only" persona that omits any integrations entirely will
have those ctx.<provider> clients be undefined; reference the example's
schedules, integrations, event.source/event.name checks, and the
handler/ctx.slack! usage to guide placement of the clarifying note.
---
Nitpick comments:
In `@web/content/docs/proactive-agents.mdx`:
- Around line 197-203: Add a short explanatory sentence about ttlDays
immediately before the example so readers know it controls memory
retention/expiration (e.g., how long saved memories persist and are eligible for
recall), then present the JSON snippet with "memory": { "enabled": true,
"scopes": ["workspace"], "ttlDays": 60 }; reference the memory.enabled,
memory.scopes, and ttlDays fields so the reader can connect the description to
the example.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 7e8979e6-d84d-4ffd-8180-6188209bf2ab
📒 Files selected for processing (3)
web/components/docs/DocsNav.tsxweb/content/docs/proactive-agents.mdxweb/lib/docs-nav.ts
…lDays CodeRabbit feedback on #952: 1. The Cron-based example declared github + slack and used ctx.slack! for the digest, but a later sentence said "cron-only personas get all integration fields as undefined." That contradicts the example. Split the two roles: declaring an integration without triggers[] only enables client access; triggers[] is what turns it into a radio listener. The "no clients" rule applies to personas that declare no integrations at all. 2. ttlDays appeared in the memory example with no explanation. Added one line on retention semantics + the "omit to keep indefinitely" case. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Adds a single docs page documenting how to build a proactive agent — a persona with one or more listeners that fire without a human in the loop. There was nothing on the topic in the docs today; the workforce-side machinery has shipped but the surface was undocumented.
Covers:
Filed under Advanced, after Workforce.
Test plan
🤖 Generated with Claude Code