Flow Agent redundant requirements for Actions and Sub-Agents

## Overview

Flow agents in the MemberJunction AI framework currently require redundant configuration for both Action steps and Sub-Agent steps. This issue documents the current behavior and suggests potential improvements for future consideration.

## Current Behavior

### For Action Steps in Flow Agents:
1. **Step Configuration**: The AIAgentStep entity specifies an `ActionID` directly
2. **Additional Requirement**: Must also have an `AIAgentAction` record linking the Flow agent to that Action
3. **Validation**: The system checks both conditions - if the AIAgentAction record is missing, execution fails with: `Action "ActionName" Not Found for Agent "AgentName"`

### For Sub-Agent Steps in Flow Agents:
1. **Step Configuration**: The AIAgentStep entity specifies a `SubAgentID` directly
2. **Additional Requirement**: The sub-agent must have its `ParentID` set to the Flow agent's ID
3. **Validation**: The system enforces this parent-child relationship - without it, execution fails with: `Sub-agent 'SubAgentName' not found`

## Code References

### Action Validation (base-agent.ts:3227-3256)
```typescript
const agentActions = AIEngine.Instance.AgentActions.filter(aa => aa.AgentID === params.agent.ID);
const actionEntity = actionEngine.Actions.find(a => a.Name === aa.name &&
agentActions.some(aa => aa.ActionID === a.ID));
if (!actionEntity) {
throw new Error(`Action "${aa.name}" Not Found for Agent "${params.agent.Name}"`);
}
```

### Sub-Agent Validation (base-agent.ts:2855-2856)
```typescript
const subAgentEntity = AIEngine.Instance.Agents.find(a => a.Name === subAgentRequest.name &&
a.ParentID === params.agent.ID);
if (!subAgentEntity) {
throw new Error(`Sub-agent '${subAgentRequest.name}' not found`);
}
```

## The Redundancy Problem

For Flow agents specifically:
- **Flow steps are deterministic** - they already specify exactly which Actions/Sub-Agents to execute via `ActionID`/`SubAgentID`
- **Additional associations are redundant** - The same relationship is defined in two places
- **Configuration overhead** - Administrators must maintain relationships in multiple locations

This differs from Loop agents, which:
- **Dynamically select actions** based on LLM decisions
- **Need an allowlist** for security/authorization
- **Benefit from explicit associations**

## Potential Improvements

### Option 1: Type-Specific Validation
Make the validation requirements dependent on agent type:
- **Flow Agents**: Trust the step configuration as source of truth
- **Loop/Dynamic Agents**: Continue requiring explicit associations

### Option 2: Optional Flag
Add a configuration flag like `RequireExplicitAssociations` on the agent type level

### Option 3: Automatic Association
When creating Flow agent steps, automatically create the necessary AIAgentAction records or parent relationships

## Benefits of Current Design

While redundant, the current approach does provide:
1. **Consistency** - Same validation logic across all agent types
2. **Security layer** - Explicit allowlist even for deterministic flows
3. **Audit trail** - Clear record of which agents can use which resources

## Impact

- **Low Priority** - Current design works, just has configuration overhead
- **No Breaking Changes Required** - Any improvements would be backward compatible
- **Documentation Opportunity** - Could better explain why these requirements exist

## Related Files
- `/packages/AI/Agents/src/base-agent.ts`
- `/packages/AI/Agents/src/agent-types/flow-agent-type.ts`
- `/packages/AI/Agents/src/agent-types/base-agent-type.ts`

## Next Steps

This is documented for future consideration. The current pattern works and doesn't cause functional issues, but could be streamlined for Flow agents specifically to reduce configuration requirements.