Inspiration
I started DOLET because I wanted to build something beyond a chatbot. I wanted software that could remember what it was doing, make a plan, use tools, stop when it needed permission, and continue working instead of starting from zero every time.
The idea behind DOLET is that the AI model should not have to be the entire system. Models can provide intelligence and reasoning, while a persistent Core owns identity, memory, plans, permissions, execution, task state, verification, and history.
DOLET is not designed specifically for games, documents, or any single type of task. My goal is to build a general-purpose persistent software robot that can gain different capabilities through authorized tools and APIs while keeping the same Core identity and operational state.
For this hackathon, I wanted to demonstrate that architecture through real work rather than only conversation. I also wanted to explore what happens when a persistent software robot is given access to an external service that can modify real documents.
Documents can contain private or sensitive information, so simply giving an AI access to a document API did not feel like enough. DOLET needed to be able to perform the work while still keeping the owner in control.
That is why I integrated Nutrient DWS as a document capability inside DOLET.
What it does
DOLET is a general-purpose persistent software robot designed to remember, plan, act, and persist.
Gemini 3.5 Flash provides reasoning through the Google Gen AI SDK, while DOLET Core remains responsible for the operational system around that intelligence.
The Core manages:
- Persistent identity and memory.
- Goal planning.
- Owner-controlled permissions.
- Task state and multi-step execution.
- Authorized tools.
- Verification of results.
- Audit history.
- Taskmaster, which brings these systems together to execute complete workflows.
This separation is important to the architecture. The reasoning provider can be replaced without replacing DOLET's identity, memory, permissions, task state, or operational history.
The game shown in my demo is only one demonstration of DOLET's capabilities. DOLET is not a game generator.
I ask DOLET to create a self-contained playable space game. DOLET reasons about the goal and uses its authorized workspace capabilities to create a working HTML, CSS, and JavaScript artifact with spacecraft controls, asteroids, collectible stars, scoring, shields, and Start and Retry controls.
The purpose of this demonstration is to show that DOLET can take a goal and use its Core and tools to produce a real working artifact. Other tools and integrations can give the same persistent Core completely different capabilities.
I then demonstrate this by moving from software artifact creation into a document workflow.
For the mission workflow, DOLET creates a classified mission report and uses its Documents capability powered by Nutrient DWS.
DOLET can:
- Convert documents to PDF using Nutrient DWS.
- Permanently redact requested text from PDFs using Nutrient DWS.
- Stop before a document transformation if
documents.transformhas not been approved. - Continue the task after the owner gives permission.
- Keep generated documents inside its controlled document workspace.
- Refuse to silently overwrite an existing output.
- Verify that an output was actually created before reporting the task as successful.
- Keep failed task state so an operation can be explicitly retried instead of pretending it worked.
- Record the workflow in its audit history.
In the demonstrated workflow, DOLET converts the mission report into a classified PDF and then uses Nutrient DWS to permanently redact the confidential operative ID, producing a public version of the document.
Nutrient DWS performs the actual document transformation, while DOLET remains responsible for the surrounding operational workflow: planning, permission, execution, task state, verification, and audit.
This demonstrates the broader architecture I am building: DOLET remains the persistent robot, while specialized tools and APIs expand what that robot can do.
How we built it
I built DOLET in Python around a persistent Core rather than around a single AI model.
Gemini 3.5 Flash is currently used as the reasoning provider through the Google Gen AI SDK. Gemini can reason about a goal and propose actions, but it does not own DOLET's persistent state or permissions.
DOLET Core remains authoritative over identity, memory, plans, permissions, tools, execution, task lifecycle, verification, and audit history.
Conceptually, a workflow moves through the system like this:
User goal → memory → planning → Gemini reasoning → permission → tool execution → result → verification → audit
Taskmaster brings these components together during multi-step work, tracking the goal and its execution through the Core.
This architecture means the reasoning intelligence is replaceable. A reasoning provider can change without requiring DOLET to lose its identity, memories, permissions, plans, or operational history.
For document processing, I extended the existing Core with a separate document provider rather than putting document logic inside the AI provider.
Nutrient DWS is the first provider for the Documents capability. I integrated two real operations: document-to-PDF conversion and permanent PDF text redaction.
Both operations go through DOLET's Core permission system. The documents.transform permission can prevent a transformation from executing until the owner authorizes it.
I also added validation around document paths and outputs. Generated files are restricted to the controlled document workspace, existing files are protected from accidental overwrites, provider errors are handled as failures, and DOLET verifies successful outputs before completing a task.
The same Core architecture can coordinate very different kinds of work.
In the game demonstration, DOLET uses Gemini reasoning and its authorized workspace tools to create a self-contained playable web artifact.
In the Nutrient workflow, the Core instead coordinates specialized document tools to perform PDF conversion and permanent redaction.
Neither workflow defines what DOLET is.
The game is one example of artifact creation, and Nutrient DWS is one example of an external capability. DOLET itself remains a general-purpose persistent software robot designed to gain more capabilities as additional tools and APIs are connected.
The Nutrient integration was tested against the real Nutrient DWS service rather than a mocked document API. Both PDF conversion and permanent redaction completed successfully through the integration.
DOLET also has an automated test suite covering its Core behavior and integrations.
Challenges we ran into
One of the hardest parts was connecting external capabilities without weakening the controls already inside DOLET.
Calling an API is relatively straightforward. Making sure a persistent task stops before an unauthorized action, survives failure, resumes correctly, verifies its output, and does not report success when nothing was created is much harder.
External services also introduce another source of failure. Credentials can be unavailable, requests can fail, outputs can be missing, or a task can be interrupted during execution.
During testing, I encountered this when the Nutrient credential was unavailable. The operation failed and DOLET did not report a successful result. After the credential was restored, the persisted task could be explicitly retried and completed successfully.
That failure became a useful test of the architecture because it demonstrated why the external API and the persistent task system should remain separate.
Another challenge was allowing Gemini to reason about increasingly complex tasks without making Gemini responsible for the entire application.
I wanted the model to provide intelligence while keeping authorization, persistent state, and execution inside DOLET Core.
That distinction became especially important as DOLET moved from conversations into multi-step tasks, artifact creation, and real document transformations.
Accomplishments that we're proud of
I am proud that this is not simply a Nutrient API call attached to an AI interface.
DOLET controls the workflow around that integration: planning, permission, execution, failure handling, persistence, verification, and audit.
I am also proud that the same Core can demonstrate very different kinds of work.
In one workflow, DOLET creates a playable space game as a working artifact.
In another, it coordinates a sensitive document workflow using Nutrient DWS to convert a mission report to PDF and permanently redact confidential information.
The Core Inspector exposes the systems behind those workflows through Memory, Planner, Permissions, Audit, and Taskmaster instead of hiding the operational architecture behind a conversation interface.
I deliberately kept the Nutrient integration focused. Rather than adding many document endpoints simply to increase the feature count, I concentrated on two useful operations—PDF conversion and permanent redaction—and integrated them into DOLET's existing permission, task, verification, and audit model.
Most importantly, the document operations were tested against the real Nutrient DWS service.
What we learned
Building this project reinforced something I have been thinking about throughout DOLET's development: giving AI more tools also gives it more ways to make mistakes.
A powerful reasoning model alone does not answer operational questions such as:
Is this action authorized?
What information should persist?
Where is the system allowed to write?
Which tool should perform the work?
Did that tool actually succeed?
What happens if execution stops halfway through?
Can the task continue without losing its state?
And can the owner see what the system actually did?
Gemini may provide reasoning about a task, and an external service such as Nutrient DWS may perform a specialized operation, but DOLET still needs a persistent system around both of them.
Building the Nutrient integration made that distinction much more concrete because DOLET was working with real files and a real external API.
It reinforced the architecture I want to continue developing: intelligence can be replaceable, tools can be expanded, but the persistent robot remains responsible for continuity, authorization, execution, and history.
What's next for DOLET
My longer-term goal is to develop DOLET into a persistent software robot capable of working across increasingly complex and long-running goals.
I want to expand its specialized tools, develop stronger semantic and relational memory, improve task scheduling and autonomy, strengthen sandboxing and production security, and eventually support persistence and synchronization across multiple devices.
I also want DOLET to gain broader computer, device, document, web, and integration capabilities so that it can handle many different categories of real-world work.
The goal is not to turn DOLET into a game generator, document processor, or any other single-purpose application.
Instead, those capabilities should become tools available to the same persistent robot.
As DOLET grows, I want it to be able to receive a goal, remember the relevant context, create and track a plan, use the appropriate reasoning provider, request authorization when necessary, operate specialized tools, verify the results, preserve its state, and maintain an accountable history of the work.
The underlying principle will remain the same: intelligence should be replaceable while DOLET Core remains authoritative over identity, memory, plans, permissions, tools, execution, persistent state, and audit history.
New models, APIs, and tools should make DOLET more capable without becoming DOLET itself.
Nutrient DWS demonstrates that direction today. It is not the purpose of DOLET; it is an example of how a specialized external capability can become an authorized tool inside a persistent system.
The playable game demonstrates another part of that same idea: DOLET can use a different set of tools to accomplish a completely different goal.
What I have built for this hackathon is the foundation.
My goal is to keep growing DOLET into a dependable digital worker that can stay with its owner across projects, remember what matters, understand what has already been done, continue unfinished work, gain new capabilities through tools and APIs, and turn increasingly complex goals into real completed work.
Log in or sign up for Devpost to join the conversation.