Octopus
Limitations and Trade-offs
The SemanticKernelPlugin adds powerful capabilities but also adds complexity and overhead. Use it when the specific SK features are needed; otherwise, the native Octopus LLM provider is simpler and faster.
When to Use SK Plugin vs Native Octopus
| Scenario | Recommendation | Reason |
|---|---|---|
| Standard conversational agent | Native Octopus LLM provider | Lower overhead, simpler debugging, same performance |
| MCP tool-calling agent | Native Octopus LLM provider | MCPToolRegistry is purpose-built for this; no SK needed |
| Multi-step task decomposition | SemanticKernelPlugin with Planner | SK planner handles decomposition natively |
| Existing SK skill library to reuse | SemanticKernelPlugin | Avoid rewriting existing SK prompt templates |
| Per-step model routing (expensive/cheap) | SemanticKernelPlugin | SK multi-service kernel makes this straightforward |
| Anthropic Claude or custom LLM | Native Octopus LLM provider | SK's connector support varies; Octopus ILLMProvider is model-agnostic |
Known Limitations
| Limitation | Details | Workaround |
|---|---|---|
| SK Planner cost | Each plan step may require 2–3 LLM calls (plan + execute + verify) | Set MaxSteps conservatively; monitor token spend |
| SK version coupling | Microsoft.SemanticKernel API changes frequently; upgrading may require plugin updates | Pin the SK version; test upgrades carefully |
| No Octopus 4-memory-type integration for SK planner | The SK planner does not automatically read episodic or procedural memory | Inject memory context into the goal string passed to the planner |
| Streaming support | SK planner does not support streaming responses — the full plan result arrives at once | Use SSE streaming only for non-planner turns |
| Debugging complexity | Plan steps are not visible in the Octopus conversation log by default | Enable SK's built-in invocation logging and forward to your observability stack |
Performance Impact
| Feature | Additional Latency | Additional Token Cost |
|---|---|---|
| SKLLMProvider (no planner) | ~5 ms overhead vs native | None |
| SK Planner (simple 3-step plan) | +1–3 seconds per step | ~2,000–5,000 tokens per plan |
| SK Memory bridge | < 1 ms per lookup vs direct store access | None |
| SK Native functions | Same as MCP tools — negligible wrapper overhead | None |
Recommendation. Start with native Octopus features (MCP tools, 4 memory types). Add SemanticKernelPlugin only when you specifically need SK planner, SK skill libraries, or per-step model routing. The added complexity is not justified for standard agent patterns.