Independent deployment & self-hosting guide
Bring research, planning, writing, and recurring work into a workspace you choose to run. With openduet, you can organize named AI agents around clear responsibilities, connect a compatible engine, and review work as it develops.
This independent site helps you understand openduet before you deploy it. Explore practical workflows, learn where your data goes, and start with a small task rather than an unrestricted automation promise.
Open-source foundation. Bring your own model access. Experimental software. This website is not the official upstream project.
A small, supervised workflow
Save the draft to your workspace
Review before continuingOpen source, thoughtfully approached.
01 / THE IDEA
openduet is an open-source workspace for working with named AI agents. Instead of starting every request in an unrelated chat, you can give an agent a role, instructions, a working folder, and an approval setting.
A researcher might examine project materials, while a writer turns reviewed notes into a useful draft. A lead agent can coordinate supported delegation workflows, helping you follow how individual contributions come together.
The purpose of openduet is not to remove your judgment. It is to make responsibilities, context, and review easier to organize. You still choose the engine, define the task, inspect the result, and decide what should happen next.
Use this openduet guide to understand that working model before connecting important files or accounts.
02 / THE BUILDING BLOCKS
Set the direction. Review the result.
Create a focused role with instructions that describe the expected result, relevant materials, and boundaries. In openduet, a useful agent starts with a specific responsibility, not an open-ended request to handle everything.
Agent notes and conversation history can help preserve relevant context between tasks. Review and edit remembered information rather than assuming every stored detail remains accurate. openduet gives you a place to manage that ongoing context.
Choose an approval mode appropriate to the work. Start cautiously when commands, file changes, or connected services are involved. An openduet workflow should make review understandable, while operating-system permissions and other security controls remain necessary.
Turn a useful prompt into a scheduled or manually triggered routine. The backend must remain running, and a routine does not approve its own actions. Treat openduet automation as supervised recurring work, not a guarantee of unattended success.
03 / IN PRACTICE
Imagine preparing a weekly project briefing from a folder of notes and reports.
First, define the audience and the questions the briefing should answer. Give your openduet agents access only to the materials needed for that task, then select an engine that supports the intended workflow.
Next, ask a researcher to identify decisions, unresolved questions, and supporting evidence. A writing agent can shape those findings into a draft. Where supported and configured, a lead agent can coordinate specialist contributions inside openduet.
Finally, review the output against the original sources. Correct unsupported claims, approve appropriate actions, and keep a record of what worked.
Only after that process is useful should you create a recurring openduet routine. Begin with a reviewable draft, not an automatic message sent to your entire organization.
Non-sensitive notes → reviewed draft04 / EVERYDAY POSSIBILITIES
Recommended first step
Weekly project briefing
Collect findings from materials you provide, organize open questions, and prepare a briefing for human review. An openduet research workflow should distinguish source-backed statements from suggestions that still need verification.
Turn approved notes into outlines, documentation, or first drafts. Give the writing agent a reader, purpose, and style. Use openduet to support your editorial process, while keeping factual checks and final publication decisions with a person.
Ask openduet for help investigating a bounded issue or planning a change in a designated workspace. Review proposed commands and file edits carefully. Keep backups and version control outside the agent’s judgment.
Prepare a weekly summary, revisit a checklist, or organize follow-up work. Start an openduet routine only after testing the same task manually and understanding what happens when a run needs attention.
05 / YOUR ENGINE
The workspace and the model are separate parts of the system. openduet does not include a hosted model or a model subscription.
The openduet upstream documentation describes several engine options, including command-line agents and compatible API connections. Availability depends on your version, provider, and the capabilities of that connection.
Before selecting an engine for openduet, confirm authentication requirements, supported tools, account terms, and usage charges. Do not assume that a feature available through one engine works identically through another.
Start with one working connection. Test a small prompt, inspect the response, and verify any required tools before adding a more complex openduet workflow.
06 / YOUR DATA
Self-hosting openduet gives you responsibility for the instance you run. It does not automatically mean that every part of an AI task stays offline.
Conversations, agent notes, routines, and settings are stored by your openduet instance. Workspace files remain in the locations assigned to agents, subject to your deployment configuration and permissions.
When an agent responds, the chosen engine receives the prompt and relevant context needed for that turn. If you connect a hosted provider, that information is handled under the provider’s terms.
Before using openduet with sensitive material, review the complete data path: application storage, model requests, connected services, logs, and backups. Use limited permissions and test with non-sensitive data first.
07 / GETTING STARTED
Guide pinned to upstream revision87d71d7055dd
Read the upstream requirements and select a supported deployment route. A server-based openduet instance needs an appropriate host, HTTPS, persistent storage, and a compatible engine connection.
Use the upstream openduet self-hosting guide for the revision you deploy. Record that revision and keep configuration files outside public repositories. Do not substitute guessed commands or unverified container tags.
Set the owner’s authentication, protect the instance, and back up both application data and the required encryption key. A backup that cannot be restored is not a complete recovery plan for openduet.
Connect an engine, create a narrowly scoped agent, and test an ordinary conversation. Then inspect approvals and a limited workflow. Expand openduet only when you understand its behavior and failure cases.
08 / RUNNING COSTS
Open-source software and free operation are different things.
Your openduet setup may involve server hosting, model usage, storage, backups, and optional external services. The total depends on your engine, task frequency, context size, and deployment choices.
Start with a modest workload and inspect provider billing alongside application-reported usage. Do not treat a displayed estimate as a replacement for your provider’s invoice.
This site does not promise free model access, unlimited execution, or a hosted subscription. Before expanding an openduet workflow, understand which service is responsible for each charge and how you can stop recurring work.
09 / A GOOD FIT?
Experimental, single-owner software
openduet may suit an individual who wants to experiment with a self-managed AI workspace and is comfortable maintaining the environment around it.
openduet is a more demanding choice if you expect a fully managed service, organization-wide account administration, or unattended handling of important operations.
The upstream server is experimental and intended for one owner with paired devices. Do not present an ordinary openduet installation as a ready-made multi-tenant platform.
Some integrations and newer capabilities also carry qualification limits. Check the documentation for your deployed revision, keep external permissions narrow, and review changes before updating. Important work needs a recovery plan and a human owner.
Read the upstream limitations10 / QUESTIONS
No. openduet is a workspace that connects to an engine you configure. Model access, account requirements, and usage charges remain separate from the application.
The openduet upstream project documents a self-hosted server route. It is experimental and designed for one owner with paired devices, rather than public registration or multiple independent customer accounts.
No. A hosted engine connected to openduet may receive prompts and relevant context. Review your engine configuration and provider terms before using sensitive material.
A routine can run through the backend when the server remains available. Test scheduling and approval behavior in your own environment rather than assuming every task will finish unattended.
No. openduet.net is an independently operated deployment and information site based on the upstream open-source project. Use the linked repository for upstream source code and project documentation.
No. The owner’s application instance is private. The public website explains the software and deployment approach; it does not offer anonymous access to the owner’s files, credentials, or model accounts.
Choose one useful task, one compatible engine, and one reviewable result. Build confidence through a small deployment before adding more agents, connected services, or recurring work.
Explore the source, understand the limitations, and make openduet part of a workflow you can explain, inspect, and maintain.