Duplicate agent

[sarah-inkeep]

Allow users to duplicate an agent in the same project as the original agent. https://linear.app/inkeep/issue/PRD-5932/allow-users-to-duplicate-and-modify-existing-agents-in-ui

https://www.loom.com/share/ae08b9b6d8d14af79045464aebc0d208

[changeset-bot]

🦋 Changeset detected

Latest commit: 3e94ec9

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

This PR includes changesets to release 10 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/agents-work-apps	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	Feb 6, 2026 1:59am
agents-docs	Ready	Preview, Comment	Feb 6, 2026 1:59am
agents-manage-ui	Ready	Preview, Comment	Feb 6, 2026 1:59am

[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.

---

[amikofalvy]

I want to do a refactor after you merge this functionality to better handle DB specific error code catching.

[amikofalvy]

Just to confirm, this change was generated from the script and fumadocs package, yes?

[amikofalvy]

This schema doesn't match the API. The API has a max character restriction. Can we derive the duplicateAgentSchema from the schema exported from agents-core? Then we will be able to have our frontend and backend schema validation automatically in sync.

[amikofalvy]

It looks like this might be duplicate default value for newAgentName? other value is defined in manage/routes/agent.ts (https://github.com/inkeep/agents/pull/1663/changes#diff-dd956509456b777e1f3f68474c6ce67478761c28396fdabb7e576c33ded6e7a4R299) and described in a third location here: https://github.com/inkeep/agents/pull/1663/changes#diff-a6b7ad468243ec559f66f3a1cb18b172f224383d7a2f31a15a6c3657f20103d3R2204-R2212 agents-core/validation/schemas.ts

[amikofalvy]

can we make newAgentName schema inherit from the original agentName schema so that they remain in sync?

[amikofalvy]

default name is defined yet again at the data access layer. I think we need to reduce default name definitions to one location.

[amikofalvy]

optimization that should be done within this PR. Parallel data fetches for all resources, otherwise this operation will take longer than it needs to.

[amikofalvy]

Additionally, parallel inserts if at all possible, there will need to be some sequencing to make sure dependencies exist before inserting some types of resources.

Additionally, think forward into the future, how will maintaining this duplication functionality have to change if we add other types of resources. I'm worried that we will add a new feature like "Agent Skills" and forget to include it in the duplication functionality. The challenge here is that all duplicated resources as explicitly defined instead of dynamically discovered.

[amikofalvy]

need to look at schema re-use, parallel db executions when possible, and making it easier to maintain this functionality when we add new agent resource types in the near and far future.

[claude]

Claude finished @sarah-inkeep's task in 6m 18s —— View job

---

PR Review Summary

1 Key Finding | Risk: Medium

🟠⚠️ Major (1) 🟠⚠️

🟠 1) packages/agents-core/src/data-access/manage/agents.ts Triggers are not duplicated

Issue: The triggers table is agent-scoped (PK includes agentId, FK cascades from agents) but is completely omitted from the duplicateAgent function. Triggers are fetched in getFullAgentDefinition (lines 889-923) showing they're part of an agent's configuration, but they're not copied during duplication.

Why: Users duplicating an agent with webhook triggers will get an incomplete copy - all integrations relying on triggers will be missing. This could cause confusion ("my duplicated agent doesn't work the same") and requires manual recreation of potentially complex trigger configurations.

Fix: Add trigger duplication logic similar to other agent-scoped entities. Add import for triggers schema and listTriggers, then include:

// After other relationship duplications (around line 1328)
const sourceTriggers = await tx.query.triggers.findMany({
  where: and(
    eq(triggers.tenantId, tenantId),
    eq(triggers.projectId, projectId),
    eq(triggers.agentId, sourceAgentId)
  ),
});

if (sourceTriggers.length > 0) {
  await tx.insert(triggers).values(
    sourceTriggers.map((trigger) => ({
      id: generateId(),
      tenantId,
      projectId,
      agentId: newAgentId,
      name: trigger.name,
      description: trigger.description,
      enabled: trigger.enabled,
      inputSchema: trigger.inputSchema,
      outputTransform: trigger.outputTransform,
      messageTemplate: trigger.messageTemplate,
      authentication: trigger.authentication,
      signingSecretCredentialReferenceId: trigger.signingSecretCredentialReferenceId,
      signatureVerification: trigger.signatureVerification,
      createdAt: now,
      updatedAt: now,
    }))
  );
}

Also add corresponding test coverage in duplicateAgent.test.ts.

---

🕐 Pending Recommendations (2)

🟠 agents.ts:1047 Parallel data fetches for all resources - sequential fetches will slow down duplication for agents with many relationships

🟡 agents.ts:1047 Maintainability for new resource types - consider how to make duplication automatically include new agent-scoped entities

---

💡 APPROVE WITH SUGGESTIONS

Summary: This is a well-implemented feature with proper transaction handling, comprehensive test coverage (926 lines of unit tests + 306 lines of integration tests), and correct tenant isolation. The schema re-use issue from prior review has been addressed - DuplicateAgentRequestSchema now properly inherits from AgentInsertSchema.shape. The main gap is that triggers (an agent-scoped entity) are not duplicated, which should be addressed before merge to ensure complete agent copies. The parallel fetches optimization raised by @amikofalvy remains valid for performance but is not blocking.

---

Other Findings (4)

Potentially valid

(these are minor or low confidence and not blocking)

Location	Issue	Reason Excluded
agent.ts:307-332	Duplicate key error detection is complex with multiple string checks	Works correctly; refactoring is nice-to-have, flagged for future DB error utility
duplicate-agent-modal.tsx:46	Default name (Copy) defined in UI	Only one location now (previous review addressed), acceptable for UI-specific default

Discarded as invalid or not applicable

Location	Issue	Reason Excluded
agents.ts:1012	Context config ID reference issue	False positive - Context configs are duplicated with preserved IDs but assigned to new agentId; lookup uses (tenantId, projectId, agentId, id) so this works correctly
agents.ts:1105	Potential unsafe cast on functionIdMapping	Type guard .filter() on line 1223 handles null cases; mapping is built synchronously before use

---

[claude]

Claude finished @sarah-inkeep's task in 3m 42s —— View job

---

PR Review Summary

1 Key Finding | Risk: Medium

🟠⚠️ Major (1) 🟠⚠️

🟠 1) packages/agents-core/src/data-access/manage/agents.ts Triggers are not duplicated

Issue: The triggers table is agent-scoped (uses ...agentScoped in schema, PK includes agentId, FK cascades from agents) but is completely omitted from the duplicateAgent function. Triggers are fetched in getFullAgentDefinition (lines 889-923) showing they're part of an agent's configuration, but they're not copied during duplication.

Why: Users duplicating an agent with webhook triggers will get an incomplete copy - all integrations relying on triggers will be missing. This could cause confusion ("my duplicated agent doesn't work the same") and requires manual recreation of potentially complex trigger configurations including authentication and signature verification settings.

Fix: Add trigger duplication logic in Phase 1 (parallel fetch) and Phase 4 (parallel inserts). Import the triggers table from schema:

// In imports (line ~15)
import { triggers } from '../../db/manage/manage-schema';

// In Phase 1 parallel fetch (add to Promise.all around line 1015)
tx.query.triggers.findMany({
  where: and(
    eq(triggers.tenantId, tenantId),
    eq(triggers.projectId, projectId),
    eq(triggers.agentId, sourceAgentId)
  ),
}),

// In Phase 4 inserts (add around line 1335)
if (sourceTriggers.length > 0) {
  phase4Inserts.push(
    tx.insert(triggers).values(
      sourceTriggers.map((trigger) => ({
        id: generateId(),
        tenantId,
        projectId,
        agentId: newAgentId,
        name: trigger.name,
        description: trigger.description,
        enabled: trigger.enabled,
        inputSchema: trigger.inputSchema,
        outputTransform: trigger.outputTransform,
        messageTemplate: trigger.messageTemplate,
        authentication: trigger.authentication,
        signingSecretCredentialReferenceId: trigger.signingSecretCredentialReferenceId,
        signatureVerification: trigger.signatureVerification,
        createdAt: now,
        updatedAt: now,
      }))
    )
  );
}

Also add corresponding test coverage in duplicateAgent.test.ts.

---

🕐 Pending Recommendations (2)

🟠 agents.ts Parallel data fetches - addressed ✅ (implementation now uses Promise.all)

🟡 agents.ts Maintainability for new resource types - consider how to make duplication automatically include new agent-scoped entities. This is a design consideration for future-proofing.

---

✅ Feedback Addressed

Prior Feedback	Status
Schema re-use (@amikofalvy)	✅ DuplicateAgentRequestSchema now inherits from AgentInsertSchema.shape
Default name duplication (@amikofalvy)	✅ Reduced to single location in UI defaultValues
Parallel data fetches (@amikofalvy)	✅ Phase 1 uses Promise.all for all 10 entity types
Frontend schema sync (@amikofalvy)	✅ UI imports DuplicateAgentRequestSchema from @inkeep/agents-core/client-exports

---

💡 APPROVE WITH SUGGESTIONS

Summary: This is a well-implemented feature with proper transaction handling, comprehensive test coverage (926 lines of unit tests + 306 lines of integration tests), correct tenant isolation, and good schema reuse. Most prior feedback from @amikofalvy has been addressed - parallel fetches are implemented, schema is properly reused from agents-core, and default name is consolidated. The main remaining gap is that triggers (an agent-scoped entity) are not duplicated, which should be addressed before merge to ensure complete agent copies. The implementation is otherwise solid and follows repository patterns well.

---

Other Findings (3)

Potentially valid

(minor or low confidence - not blocking)

Location	Issue	Reason Excluded
agent.ts:307-332	Duplicate key error detection uses multiple string checks	Works correctly; @amikofalvy already noted desire for future DB error utility refactor
duplicate-agent-modal.tsx:46	Default name (Copy) in UI	Single location now (proper place for UI-specific defaults)

Discarded as invalid or not applicable

Location	Issue	Reason Excluded
agents.ts:1138	Context config ID reference issue	False positive - Context configs are duplicated with preserved IDs but assigned to new agentId; lookup uses compound key (tenantId, projectId, agentId, id) so this works correctly

---