Separate capabilities clearly
Use the plugin-first architecture to reason about model access, tools, and workflow responsibilities as separate parts.
Use DeepSeek Harness as a reference for composing your own agent workflows. Study its plugin architecture to separate model access, tools, and task capabilities, then evaluate focused extensions for work organized in Floatboat.
DeepSeek Harness, also called dsh, is an open-source agent harness developed by DeepSeek. It provides a runtime around model interaction rather than a new model in itself. The project’s central design is to express the system through composable plugins.
Its value for workflow design is the separation of capabilities into composable parts. A Floatboat user can use that idea to identify the tools, context, and responsibilities a task requires before considering a specific plugin or runtime integration. The reference architecture does not establish a ready-made connection to Floatboat.
DeepSeek describes the project as a developer preview with compatibility-breaking changes expected. Its MIT source license is separate from model-provider access and third-party dependencies. Evaluate it as an evolving platform, with version-specific documentation and deliberate workspace boundaries.
Understand what the project demonstrates, then decide which mechanism addresses a real gap in your own workflow.
Use the plugin-first architecture to reason about model access, tools, and workflow responsibilities as separate parts.
Evaluate only the capabilities needed by the task, rather than treating a large plugin catalog as a complete working solution.
Treat version compatibility as part of workflow design so a runtime update does not silently change the expected behavior.
Use these scenarios as design references for work organized in Floatboat. Any software integration needs its own compatibility and permission checks.
Break collection, transformation, and review into explicit capabilities with clear inputs and outputs.
Study plugin contracts when an existing workflow needs a specific external tool or a task capability unavailable in the current setup.
Evaluate a small composition and record its behavior before relying on a preview-stage runtime for recurring work.
Start with a task and a small testable change, whether that means better instructions, a new tool connection, or a runtime component.
Define which information, tools, and intermediate results each stage needs, independently of a particular plugin name.
Review capability boundaries, credentials, and version compatibility for the extensions you actually need.
Verify that a failed tool or changed plugin produces a visible result and a clear decision about the next step.
Compare independent agents through their interfaces, extension models, and approach to carrying work forward.