feat: added agent handoffs - #8
Conversation
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughWalkthroughAdds triage and billing agents with distinct tool allowlists, enables runtime handoffs with agent-specific prompts and schemas, adds refund tooling, and renders handoff events in the InspectorPane. ChangesAgent Handoff Workflow
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Workflow
participant OpenAI
participant AgentRegistry
participant ToolRuntime
participant InspectorPane
Workflow->>OpenAI: Request model turn with active agent tools
OpenAI-->>Workflow: Return handoff tool call
Workflow->>AgentRegistry: Resolve target agent
AgentRegistry-->>Workflow: Return billing agent
Workflow->>Workflow: Emit agent.handoff and update active agent
Workflow->>OpenAI: Request next turn with billing prompt and tools
OpenAI-->>Workflow: Return tool call
Workflow->>ToolRuntime: Execute registered tool
ToolRuntime-->>Workflow: Return tool result
Workflow-->>InspectorPane: Stream agent.handoff event
InspectorPane-->>InspectorPane: Render source and target agents
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@harness/runtime.py`:
- Around line 171-193: Validate the handoff call’s JSON arguments and ensure its
“to” target is present in REGISTRY before emitting the agent.handoff event or
updating active. For malformed arguments or unknown targets, return an
appropriate failed tool result so the workflow continues and the model can
retry; only emit and switch for valid targets in the handoff branch of the
tool-call loop.
In `@harness/tools.py`:
- Around line 46-70: Update issue_refund to validate that amountCents is
positive and the customerId/chargeId are eligible, then execute the refund
through the payment provider before constructing a response. Return the
provider’s actual success status and refund identifier, and never report
refunded: True unless the provider confirms execution.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 348773c5-0129-4028-8235-ac6072b65bfa
📒 Files selected for processing (5)
harness/agents.pyharness/memory.pyharness/runtime.pyharness/tools.pyweb/src/components/InspectorPane.tsx
| def issue_refund(customerId: str, chargeId: str, amountCents: int) -> dict: | ||
| # IRREVERSIBLE: moves real money. The capability triage lacks. | ||
| return { | ||
| "refunded": True, | ||
| "customerId": customerId, | ||
| "chargeId": chargeId, | ||
| "amountCents": amountCents, | ||
| } | ||
|
|
||
|
|
||
| # ── the schemas (what the model reads to decide what to call) ──────── | ||
| TOOL_SCHEMAS: list[FunctionToolParam] = [ | ||
| { | ||
| "type": "function", | ||
| "strict": False, | ||
| "name": "issueRefund", | ||
| "description": "Issue a refund. IRREVERSIBLE - moves real money", | ||
| "parameters": { | ||
| "type": "object", | ||
| "properties": { | ||
| "customerId": {"type": "string"}, | ||
| "chargeId": {"type": "string"}, | ||
| "amountCents": {"type": "integer"}, | ||
| }, | ||
| "required": ["customerId", "chargeId", "amountCents"], |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Do not report a refund before one is executed.
This returns refunded: True for arbitrary charge/customer IDs and amounts without a payment-provider call or validation. The billing agent can subsequently send a false confirmation to the customer. Execute and verify the provider operation first; enforce a positive, eligible amount and return its real status/identifier.
🤖 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 `@harness/tools.py` around lines 46 - 70, Update issue_refund to validate that
amountCents is positive and the customerId/chargeId are eligible, then execute
the refund through the payment provider before constructing a response. Return
the provider’s actual success status and refund identifier, and never report
refunded: True unless the provider confirms execution.
1 participant
Summary by CodeRabbit
New Features
Improvements