"Custom" Merge in Beam Mode should use System and User instruction defaults matching standard "Fuse" Merge.

[Slava-256]

What's happening?

When I select Custom Merge in Beam Mode, I am presented with default instructions that read as follows:

System Instruction:
Your task is to synthesize a cohesive and relevant response based on the following messages: the original system message, the full conversation history up to the user query, the user query, and a set of {{N}} answers generated independently.
These alternatives explore different solutions and perspectives and are presented in random order. Your output should integrate insights from these alternatives, aligned with the conversation's context and objectives, into a single, coherent response that addresses the user's needs and questions as expressed throughout the conversation.

User Instruction:
Based on the {{N}} alternatives provided, synthesize a single, comprehensive response.

This is different from instructions used in standard Fuse mode:

System Instruction:
You are an expert AI text synthesizer, your task is to analyze the following inputs and generate a single, comprehensive response that addresses the core objectives or questions.

Consider the conversation history, the last user message, and the diverse perspectives presented in the {{N}} response alternatives.

Your response should integrate the most relevant insights from these inputs into a cohesive and actionable answer.

Synthesize the perfect response that merges the key insights and provides clear guidance or answers based on the collective intelligence of the alternatives.

User Instruction:
Synthesize the perfect cohesive response to my last message that merges the collective intelligence of the {{N}} alternatives above.

For clarity and to enable users to experiment with incremental changes to default Fuse instructions, it would be preferable to have Custom mode default to be the same as standard Fuse instructions.

Where does this happen?

Big-AGI Pro (big-agi.com)

Impact on your workflow

Medium - Workaround exists

Environment (if applicable)

No response

Additional context

No response

[github-actions]

Thanks for the detailed feature request, @Slava-256!

Assessment

This is a valid enhancement request. The Custom merge mode currently uses different default instructions than the standard Fuse mode, which makes it harder for users to experiment with incremental changes to the Fuse defaults.

Root cause: The Custom merge factory in src/modules/beam/gather/instructions/beam.gather.factories.ts (lines 167-187) has its own unique system and user prompts that differ from the Fuse mode prompts (lines 31-56).

Fix

I've updated the Custom merge mode to use the same default instructions as Fuse mode:

System Prompt (now matching Fuse):

You are an expert AI text synthesizer, your task is to analyze the following inputs and generate a single, comprehensive response that addresses the core objectives or questions.

Consider the conversation history, the last user message, and the diverse perspectives presented in the {{N}} response alternatives.

Your response should integrate the most relevant insights from these inputs into a cohesive and actionable answer.

Synthesize the perfect response that merges the key insights and provides clear guidance or answers based on the collective intelligence of the alternatives.

User Prompt (now matching Fuse):

Synthesize the perfect cohesive response to my last message that merges the collective intelligence of the {{N}} alternatives above.

This change allows users to start from the proven Fuse defaults and make incremental adjustments in Custom mode.

File changed: src/modules/beam/gather/instructions/beam.gather.factories.ts

[Slava-256]

It may be preferable to pull defaults for Custom mode directly from Fuse mode defaults. Or have some other way to ensure that there is no divergence in the future when Fuse mode defaults change and no matching change is made to Custom mode defaults.

[enricoros]

@claude See the comment above. Ultrathink the tradeoffs and suggested the best way to improve this

[claude]

Claude finished @enricoros's task in 1m 2s —— View job

---

Analysis: Custom Merge Defaults

• Gather context and understand the codebase structure
• Analyze the tradeoffs of different approaches
• Recommend the best solution

---

Understanding the Current Architecture

The beam gather system in src/modules/beam/gather/instructions/beam.gather.factories.ts defines four fusion factories: Fuse, Guided, Compare, and Custom. Each factory has a createInstructions() function that returns the prompts used for that fusion mode.

Key observation: The fusionRecreateAsCustom function in beam.gather.ts:184-204 already demonstrates a pattern where Custom mode can be initialized from any other factory's instructions:

fusionRecreateAsCustom: (sourceFusionId: BFusionId) => {
  const sourceFusionFactory = findFusionFactory(sourceFusion?.factoryId);
  // create a custom from the source fusion factory
  const newCustomFusion = createBFusion(CUSTOM_FACTORY_ID, sourceFusionFactory.createInstructions(), ...);
}

This existing pattern suggests the codebase already supports "deriving" Custom from other factories dynamically.

---

Tradeoff Analysis

Approach 1: Copy-paste Fuse prompts to Custom (Original suggestion)

Pros:

• Simple, minimal code change
• Custom retains its own identity with explicit prompts

Cons:

• Divergence risk - When Fuse prompts are updated, Custom won't automatically follow (exactly the concern raised by @Slava-256)
• Maintenance burden - two places to update
• Violates DRY principle

Approach 2: Custom references Fuse's prompts directly

// Custom factory
createInstructions: () => {
  const fuseFactory = FUSION_FACTORIES.find(f => f.factoryId === 'fuse');
  return fuseFactory?.createInstructions() ?? [...fallback...];
}

Pros:

• Zero divergence - Custom always inherits Fuse's latest prompts
• Single source of truth
• No maintenance burden

Cons:

• Creates implicit dependency (Custom silently depends on Fuse)
• Runtime lookup cost (negligible)
• If Fuse is ever removed/renamed, Custom breaks (but this would be caught at dev time)

Approach 3: Extract shared prompts to constants

const FUSE_SYSTEM_PROMPT = `...`;
const FUSE_USER_PROMPT = `...`;

// Used by both Fuse and Custom factories

Pros:

• Explicit shared dependency
• Clear intention in code
• Both factories reference same constants

Cons:

• Slightly more refactoring
• Constants file organization question

Approach 4: Extract a base "Fuse" instruction creator

const createFuseInstructions = (): Instruction[] => [...];

// Fuse factory
createInstructions: createFuseInstructions,

// Custom factory  
createInstructions: createFuseInstructions,

Pros:

• Clean, explicit sharing
• Function can be reused elsewhere
• Most idiomatic TypeScript pattern

Cons:

• Minimal refactoring required

---

Recommendation: Approach 4 (Extract shared function)

Best solution: Extract the Fuse instructions into a reusable function that both Fuse and Custom reference.

// Shared instruction creator
const createFuseStyleInstructions = (): Instruction[] => [
  {
    type: 'gather',
    label: 'Synthesizing Fusion',
    method: 's-s0-h0-u0-aN-u',
    systemPrompt: `You are an expert AI text synthesizer...`.trim(),
    userPrompt: `Synthesize the perfect cohesive response...`.trim(),
  },
];

// Fuse factory
{
  factoryId: 'fuse',
  createInstructions: createFuseStyleInstructions,
  ...
}

// Custom factory
{
  factoryId: CUSTOM_FACTORY_ID,
  createInstructions: createFuseStyleInstructions,
  ...
}

Why this is the best approach:

1. Eliminates divergence - Single source of truth, impossible for them to drift apart
2. Explicit intent - Code clearly shows Custom uses Fuse-style prompts
3. Maintainable - One place to update, both benefit
4. No runtime overhead - No dynamic lookups
5. Type-safe - Compile-time guarantees
6. Future-proof - If you want Custom to diverge later, just give it its own function
7. Follows existing patterns - Similar to how fusionRecreateAsCustom already works conceptually

This approach directly addresses @Slava-256's concern: "have some other way to ensure that there is no divergence in the future when Fuse mode defaults change."

---

Would you like me to implement this change?