Duplicate agent

[sarah-inkeep]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: 88c3840

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@inkeep/agents-core	Patch
@inkeep/agents-manage-ui	Patch
@inkeep/agents-api	Patch
@inkeep/agents-cli	Patch
@inkeep/agents-sdk	Patch
@inkeep/ai-sdk-provider	Patch
@inkeep/create-agents	Patch
@inkeep/agents-manage-mcp	Patch
@inkeep/agents-mcp	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-api	Ready	Preview, Comment	Jan 31, 2026 3:33am
agents-manage-ui	Ready	Preview, Comment	Jan 31, 2026 3:33am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
agents-docs	Skipped		Jan 31, 2026 3:33am

[claude]

Claude finished @sarah-inkeep's task —— View job

---

Code Review Complete

This PR implements a comprehensive duplicate agent feature across all layers of the system. The implementation follows the repository's patterns well and includes proper testing, UI components, and API documentation. Here's my detailed review:

✅ Strong Points

Architectural Design

• Transaction-wrapped duplication: The duplicateAgent function properly wraps the entire operation in a database transaction, ensuring atomicity
• Comprehensive relationship copying: Successfully duplicates all related entities (sub-agents, tools, relations, components, etc.)
• Batch operations: Uses efficient batch inserts with Promise.all for performance optimization
• ID mapping strategy: Smart handling of function tool ID remapping while preserving sub-agent IDs

Implementation Quality

• Proper error handling: API route includes specific error codes (409 for conflicts) and appropriate HTTP status codes
• Input validation: Strong Zod schemas with proper constraints (URL-safe IDs, length limits, reserved name prevention)
• UI/UX: Clean modal implementation with auto-prefill ID functionality and proper loading states
• Test coverage: Comprehensive unit and integration tests covering the core functionality

🔍 Areas for Consideration

Performance & Scalability

1. Large agent duplication: The current implementation loads all relationships in memory simultaneously. For agents with hundreds of relationships, consider:

   // Consider pagination or streaming for very large agents
   const batchSize = 100;
   for (let i = 0; i < sourceSubAgents.length; i += batchSize) {
     const batch = sourceSubAgents.slice(i, i + batchSize);
     await tx.insert(subAgents).values(batch.map(...));
   }

2. Deep copy vs shallow references: The implementation creates new IDs for most entities but preserves sub-agent IDs. This could lead to confusion - consider documenting this design decision or making ID generation more consistent.

Security & Authorization

3. Permission inheritance: The API doesn't explicitly validate that the user has permission to create agents in the target project. While the existing auth middleware likely handles this, consider adding explicit checks for the duplication operation.

4. Resource quotas: No validation of project limits - duplicating large agents could exceed tenant resource quotas.

Data Consistency

5. Context config ID handling: Line 962 in packages/agents-core/src/data-access/manage/agents.ts:

   contextConfigId: sourceAgent.contextConfigId, // ⚠️ Potential issue

   This preserves the original context config ID, but context configs are agent-scoped. If the context config is duplicated separately, this could create a dangling reference.

6. Circular relationships: No validation for potential circular sub-agent relationships that could be created through duplication.

Error Handling

7. Partial failure recovery: If duplication fails partway through, the transaction rollback is good, but error messages could be more specific about which stage failed:

   try {
     // Add stage tracking for better error reporting
     logger.debug('Duplicating sub-agents...');
     // ... sub-agent duplication
     logger.debug('Duplicating function tools...');
     // ... function tool duplication
   } catch (error) {
     logger.error('Duplication failed during: ' + currentStage, error);
     throw error;
   }

API Design

8. Response completeness: The API returns only the basic agent object. Consider returning a summary of what was duplicated:

   return c.json({ 
     data: duplicatedAgent,
     metadata: {
       duplicatedSubAgents: sourceSubAgents.length,
       duplicatedFunctionTools: sourceFunctionTools.length,
       // ... other counts
     }
   }, 201);

UI/UX Considerations

9. Large agent duplication UX: The modal doesn't indicate duplication progress. For large agents, consider adding a progress indicator or moving to a background job pattern.

10. Naming collision prevention: The auto-generated name pattern (Copy) could create confusion with multiple duplications. Consider (Copy 1), (Copy 2) pattern.

📝 Minor Code Quality Issues

11. Type safety in fetchComponentRelationships: The function uses any types extensively (lines 215-232). Consider improving type safety:

    export const fetchComponentRelationships = <
      TRelation extends Record<string, unknown>,
      TComponent extends Record<string, unknown>
    >(
      // ... better typing

12. Dead code in validation: Line 1129 in the duplicate function checks for null but the filter on line 1142 handles this - the null check might be redundant.

🎯 Architectural Considerations

Future Extensibility

• Consider adding a duplicateOptions parameter to control what gets duplicated (e.g., exclude certain relationships)
• The current design assumes all relationships should be duplicated - may need flexibility for different use cases

Audit & Observability

• Consider adding audit logging for agent duplication events
• The operation could benefit from OpenTelemetry tracing spans for debugging

Documentation Completeness

• Missing public-facing documentation in /agents-docs/ (though this follows the pattern for internal features)
• API documentation is auto-generated and complete

🏆 Overall Assessment

This is a well-implemented feature that demonstrates strong understanding of the codebase architecture. The implementation correctly follows the repository's patterns for:

• ✅ Database operations with proper transaction handling
• ✅ API route structure and error handling
• ✅ UI component patterns and form validation
• ✅ Comprehensive test coverage
• ✅ Proper changeset creation

The performance optimizations using batch operations and the atomic transaction wrapper show thoughtful engineering. The identified considerations are primarily about edge cases and potential scalability improvements rather than fundamental issues.

Recommendation: Approve with the understanding that the identified performance and security considerations can be addressed in follow-up iterations as usage patterns emerge.

---