ai newsDo., 15. Okt.
EilmeldungMeta and Apple team up to make Muse AI models run better on Macs

When an AI Workspace Needs to Become Software

A project preserves context; a plugin adds reusable records, screens and rules. WorkDSH shows when AI work should become software.

HackerNoonDonnerstag 09:22 · 15.10.5 Min. Lesezeit
Bild: HackerNoon

Signup Write New Story When an AI Workspace Needs to Become Software by 王涛 by 王涛 | @ techflag Independent AI developer and WorkDSH maintainer. Building AI applications, agents, and plugins. Open to freelance projects.

Independent AI developer and WorkDSH maintainer. Building AI applications, agents, and plugins. Open to freelance projects.

I started WorkDSH with a question that many AI product builders eventually face. A workspace can collect documents, keep projects, install skills, assign specialist roles, and connect external services. Once all of those pieces exist, what does a plugin add?

WorkBuddy was an important product-experience reference for me. Its approach to projects and reusable capabilities showed how much better an AI task feels when it does not start from an empty chat every time. WorkDSH follows a similar path for organizing tasks, but it is an independent open-source project built on DeepSeek Harness.

As we built it, the question stopped being theoretical. WorkDSH's Projects page is itself supplied by a WorkDSH plugin. A user's project stores the context of one piece of work. The Projects plugin is the software that makes that kind of work possible in the first place.

The Projects view is real. The particular projects shown belong to a local workspace and are not included in every installation.

Consider a factory maintenance team. For one piece of equipment, a project can hold manuals, previous repair notes, inspection tasks, and the conversation around a fault. A diagnostic skill can suggest what to check next. An expert configuration can guide the investigation, while an authorized connector can retrieve readings from an existing system. The team can continue the investigation in the same project without developing new software.

Now imagine that every inspection must follow the same controlled process. A technician records readings against identified inspection points and the approved threshold version. An out-of-range result must open an exception. The equipment cannot be marked ready until a qualified person completes and signs the reinspection.

The team can write these rules in a document and ask AI to remind them. That may help people notice a step, but the operation still needs identified records, visible status, authorization checks, and a reliable history of who signed what. A project keeps the fault's context. It does not automatically implement this shared inspection operation.

This is related to a distinction raised in HackerNoon's discussion of AI agents and durable state: model context is useful, but the state of a business process has to survive the model call. For the inspection example, that state includes the exception, the approved threshold version, and the human sign-off.

That is a defensible point at which to build an inspection plugin. It would create the records, screens, states, and checks that many equipment projects can use. Skills, expert configurations, and connectors would continue to contribute suggestions and external information. The final safety confirmation would remain with qualified people.

The distinction matters because it avoids building software for its own sake. If the factory already uses a suitable maintenance system, a connector may be enough. If a suitable community plugin exists, install it. Build a new plugin when the missing operation really belongs in the workspace and will be reused.

The inspection application is a hypothetical example. It is not part of the current WorkDSH release.

DeepSeek Harness treats plugins as a way to extend what the host can do. WorkDSH keeps the upstream Harness implementation separate and adds product features through published extension points. Projects, the local Library, Skills management, and Experts management are WorkDSH features delivered this way. A plugin might expose a tool; it might also contribute a page and a service that own a particular kind of record.

This is the longer-term reason I care about the architecture. A developer can add a class of operation to the software and then let many projects use it. The boundary is visible in code, and each module can be installed and maintained on its own terms. Compatibility with future Harness versions still has to be checked; plugin architecture does not make maintenance disappear.

The WorkDSH Skills view now surfaces the public SkillHub catalog. Users can discover a skill, inspect its source and version, and choose whether to install it. The large catalog count shown in the interface is not a count of preinstalled skills.

Actual local Alpha screenshot; installed items are specific to the machine used for the capture.

The community plugin route is separate. The independently maintained dsh-market is itself a DSH plugin. Once a user installs it, WorkDSH can show the market's plugin-discovery page inside the product. Its listings are not automatically bundled, audited, or endorsed by WorkDSH.

Actual local screenshot after installing the third-party market plugin.

Desktop preview packages also include the Node.js and Python runtimes needed for WorkDSH startup. That removes a setup step for an ordinary user, although individual community plugins may require more.

I do not think this argument depends on pretending that other products cannot build applications. WorkBuddy has its own Buddy Apps path. WorkDSH's choice is to expose an open-source plugin path on DeepSeek Harness. The useful question is what a builder can change, how that change is distributed, and who maintains it after installation.

WorkDSH is still in Alpha. The real modules and the ecosystem entry points can be explored today; the inspection application above remains an example of what a future plugin could do. The source, downloads, and current limitations are public for anyone who wants to inspect that boundary closely.

Disclosure: I maintain WorkDSH. It is an independent project, not affiliated with or endorsed by WorkBuddy, SkillHub, or dsh-market. The inspection application is hypothetical, not a shipped feature.

AI disclosure: This article was generated with AI from project source materials. Release-specific claims were checked against the latest Desktop release notes.

Quelle: HackerNoon (HackerNoon). Original öffnen