Inspiration

AI is rapidly becoming part of everyday life, yet only a small number of people use it to write code or entrust real work to autonomous agents.

When people see a website or game presented as AI-made, they often think, “I could make that easily.” The reality is different. You still have to watch the process, make countless small and large decisions, retry failed work, and finally verify that the result actually works.

I wanted to reduce that supervision burden and explore how close we could get to completion from a simple request such as “Build this for me,” at least within a clearly supported scope.

Human judgment should remain where design, taste, and personal direction matter. But what would happen if a system took responsibility for the planning, production, execution, testing, and bounded repair that AI can handle?

KHALINOS began with that question.

What it does

KHALINOS is a bounded agentic production system. Once a user defines a goal, success criteria, and budget, and then authorizes execution, it continues production and verification within a supported task scope.

The user first provides source material and a goal. KHALINOS analyzes them and identifies subjective decisions that the system should not make on the user’s behalf. Through SixSense, a set of up to six focused questions, it clarifies the expected outcome and success conditions.

Before execution, KHALINOS presents a Preview of the expected result and the criteria that will be applied. Once authorized, that Preview becomes an immutable contract that cannot be silently changed during execution.

KHALINOS then composes the Capability Packs required for the selected Profile and binds them only to the agents responsible for each role. The agents carry out planning, production, execution, inspection, and verification.

Every milestone contains smaller quests and evidence requirements. The workflow can advance only after those conditions are satisfied. If inspection discovers a repairable problem, KHALINOS performs a bounded correction based on the evidence. It does not retry the same task indefinitely without a reason.

KHALINOS does not report success simply because an agent says that it is finished. The actual execution result, deterministic checks, artifact hashes, receipts, and the decision of a role-separated Verifier must agree before a verified result is delivered.

The current version supports and has verified three Profiles:

  • Trinity: a Godot top-down combat prototype with class progression.
  • Side-scroll destination: a Godot game in which a party advances toward a destination and fights enemies automatically.
  • Browser launch triage: a Browser application that evaluates launch readiness and blocking issues.

The live KHALINOS interface displays the selected Profile, composed Capability Packs, active agent, milestones, Google Cloud execution ID, Gemini calls, receipt progress, Verifier state, and elapsed time.

How we built it

KHALINOS is built around Gemini 3.5 Flash, Google ADK, and Google Cloud.

Gemini analyzes the user’s goal, creates structured plans, makes Profile-specific judgments, and participates in bounded repair. Google ADK coordinates the role-separated agent workflow responsible for planning, production, inspection, and verification.

The complete system runs on Google Cloud:

  • Vertex AI provides access to Gemini.
  • Cloud Run hosts the public KHALINOS application.
  • Cloud Run Jobs executes production and verification work in isolated workers.
  • Firestore stores workflow state, milestones, active-agent information, and UI telemetry.
  • Cloud Storage stores artifacts, receipts, hashes, and verification evidence.
  • Python and FastAPI connect the workflow to the trusted orchestration and API layer.
  • Godot 4 produces executable results for the two game Profiles.
  • Docker provides a consistent runtime across local and Cloud environments.

KHALINOS does not give every agent the same tools or authority. It binds only the Capability Packs required for the selected Profile and current stage. An Agent–Capability binding receipt records which capabilities were assigned to each agent.

The agents are responsible for proposals and judgments, while the trusted host controls permitted tools, routes, filesystem boundaries, and deterministic checkers. This prevents a model from silently expanding its own authority or operating outside an approved execution path.

For the Godot Profiles, Gemini produces a structured plan. Trusted compilers and composed Capability Packs transform that plan into an executable Godot project. For the Browser Profile, Gemini can author HTML, CSS, and JavaScript inside a bounded route with defined verification requirements.

Artifacts, execution results, and verification evidence are connected through cryptographic hashes. This makes it possible to confirm that the artifact delivered to the user is the same artifact that passed verification.

Challenges we ran into

Almost every part became a challenge.

The original idea was a general-purpose system that could produce almost anything from a single request. At that time, the project was called OneBrief, a name suggested by AI, and its goal was to turn one brief and one approval into a finished result.

After many experiments, I realized that completing a trustworthy general-purpose production agent within the hackathon period was not realistic. Claiming that a system can make anything is very different from repeatedly delivering results that actually run and can be verified.

Capturing user taste was also harder than expected. Users do not always know how to describe what they want, and sometimes they cannot know until they see the result.

Based on those failures, I changed direction. Instead of attempting to create anything freely, I decided to build a system that minimizes user intervention while producing verified outcomes inside prepared and testable boundaries. OneBrief evolved into KHALINOS, a system focused on supervising direction as well as production.

The questions continued after the pivot.

For simple projects, I wondered whether the work was substantial enough to justify a system like KHALINOS. For complex projects, one large ToolPack could not produce enough variation or adapt to different requirements.

I divided the large ToolPack into smaller Capability Packs and made them composable by Profile. The same agent roles could then use different capability combinations for Trinity, the side-scroll game, and the Browser project.

There were also repeated technical failures: planner schemas that Vertex AI could not accept, a missing Godot runtime in the Cloud environment, an out-of-memory failure on a 2 GiB worker, empty ToolPack bindings, and sprite checks that disagreed with the actual rendered result.

I did not solve these problems by blindly repeating the same request. I identified and corrected the generalized cause of each failure: Vertex-safe schemas, cleaner Cloud build boundaries, an 8 GiB worker with the required runtime, trusted Capability binding, and render gates that permit only bounded evidence-based refinement.

Through this process, KHALINOS gradually found its role. It is not an agent that promises to make more things without limits. It holds the reins of a workflow, clarifying the user’s goal and keeping production and verification moving in the approved direction, budget, and authority boundary.

The visual quality of the more difficult Profiles is still limited. However, by keeping the scope honest, preserving evidence of failure, and improving Capability Packs instead of hiding problems, I believe KHALINOS can address increasingly difficult tasks step by step.

Accomplishments that we're proud of

The most important accomplishment is that KHALINOS actually ran on Google Cloud and produced executable artifacts.

An early fictional health-supplement proposal was relatively easy to produce. As the work became more complex, especially with games, fixing one error often introduced another. I repeatedly wondered whether I would have a working system to submit before the deadline.

Despite those doubts, KHALINOS ultimately executed and verified three distinct Profiles:

  • A Trinity Godot game with top-down combat and class progression.
  • A side-scroll Godot game with movement, automatic combat, and a destination.
  • A Browser application that evaluates launch readiness.

These were not pre-recorded screens presented as generated results. KHALINOS composed Profile-specific Capability Packs on Google Cloud, and role-separated agents carried out planning, production, execution, and verification.

The workflow records how Capability bindings change between Profiles. It recognizes PASS only when runtime results, deterministic checks, artifact hashes, receipts, and the Verifier agree.

The live interface also exposes what the system is doing: the current agent, Capability Packs, milestone progress, Gemini calls, receipts, and Verifier state.

Another important result is that the deployed KHALINOS workflow runs without Codex. Codex assisted during development, debugging, testing, and submission preparation, but the deployed production workflow executes with Gemini, Google ADK, and Google Cloud.

The games are not commercially finished products. Their visual and audio quality is closer to a gameplay prototype designed to prove real mechanics and the production-and-verification process. Nevertheless, dividing one large ToolPack into smaller composable Capability Packs demonstrated a practical path for expanding KHALINOS into additional supported tasks.

What we learned

At first, it seemed that climbing the mountain directly in front of me would make me an expert. Once I reached the top, I saw higher mountains that had previously been hidden behind it.

When I look back, I can see the version of myself who thought the first climb was an extraordinary achievement. If I had stopped there, I might have believed that I already understood enough. Moving forward exposed problems, limitations, and questions that I had not previously been able to see.

Technically, I learned that autonomy does not come from giving an agent more freedom. Reliable autonomy requires explicit authority boundaries, limited tools, separation between production and verification, and evidence from actual execution.

Gemini judgment and deterministic checks did not replace one another. The model was strong at interpreting goals and creating plans, but executable checks were necessary to prove that a result worked. Deterministic checks alone could not judge user taste or intended direction. A more trustworthy workflow emerged when the two approaches compensated for each other’s weaknesses.

I also learned that composing only the Capability Packs needed for a task is safer and more extensible than giving every tool to one agent.

On a smaller scale, this project taught me how agents can participate in both production and supervision. On a larger scale, comparing who I was before this challenge with who I am at submission time taught me how important it is to keep moving forward, even before I feel completely ready.

What's next for KHALINOS

In Blizzard’s World of Warcraft, players use Add-ons to customize and extend the game in their own way. While building KHALINOS, I imagined a similar ecosystem for Capability Packs.

KHALINOS should continue becoming stricter, more consistent, and more reliable at delivering verified results. However, I cannot personally create every specialized Capability Pack that every field may require.

What if users and developers could build and share Packs that contain their own expertise? One person might create a Pack for game combat systems, while others could create Packs for design, data analysis, document production, or web application verification.

KHALINOS could select and compose compatible Packs according to the user’s goal and Profile, allowing it to move in far more directions than I could support alone.

Allowing arbitrary shared Packs to execute without restrictions would conflict with the philosophy of KHALINOS. Each Pack would need to declare its permissions, input and output contracts, compatible Packs, license information, and verification requirements. Only Packs that pass trusted inspection and approval should be allowed into a real workflow.

Before expanding that ecosystem, I also want to strengthen the operational reliability of KHALINOS through:

  • Recovery and resumption after interrupted executions.
  • Duplicate-execution prevention and idempotency.
  • Isolation between concurrent workflows.
  • Failure injection and safe-stop testing.
  • Measurement of real user supervision time and cost reduction.
  • User evaluation of outcome quality.
  • Verification of additional Profile and Capability Pack combinations.

These improvements could make KHALINOS a faster and more reliable workhorse. But its ability to expand across specialized fields will be stronger if people with different experience can build, verify, share, and compose Capability Packs together.

Scope and disclosure

KHALINOS is not currently a general-purpose autonomous coding agent capable of freely producing every kind of software. It is a bounded agentic production and supervision system that operates within supported Profiles backed by prepared and verified Capability Packs.

For the Godot Profiles, Gemini does not freely author an arbitrary complete game codebase. Gemini produces structured plans and judgments, while trusted compilers and pre-implemented Capability Packs transform them into executable Godot projects.

I therefore do not claim that KHALINOS can currently create any kind of game. This submission demonstrates that, within two prepared and verified Godot Profiles, agent planning and different Capability combinations can produce distinct executable game results.

For the Browser Profile, Gemini authors HTML, CSS, and JavaScript within a bounded route and defined verification conditions.

The KHALINOS Verifier is role-separated from the production agents, but it is not operated by an independent external organization or audit service. It is a separate role inside the same KHALINOS environment. Deterministic checks, execution evidence, receipts, and artifact hashes strengthen its judgment, but I do not describe it as fully independent external verification.

Codex assisted with the development of KHALINOS, failure analysis, testing, deployment, and submission preparation. The deployed KHALINOS production workflow does not depend on Codex and runs with Gemini 3.5 Flash, Google ADK, and Google Cloud.

Some visual assets used in the game results came from AetherAI under its free-asset license. They are incorporated into the game artifacts and are not sold or redistributed as a standalone asset pack.

The game results are gameplay prototypes created to demonstrate KHALINOS planning, production, execution, and verification. Their movement, combat, attacks, healing, progression, victory conditions, and rendering were tested, but I do not present their visual or audio quality as commercially finished.

Development of OneBrief began during the hackathon period on August 5, 2026. After multiple general-purpose production experiments, I redefined its scope and philosophy and began the current KHALINOS repository on August 18, 2026.

KHALINOS was therefore not a completed product created before the hackathon. It is the result of OneBrief beginning during the event, encountering real limitations, and evolving into a more bounded and evidence-driven system.

The product lessons and workflow experience from OneBrief continued into KHALINOS. The current Cloud workflow, composable Capability Pack structure, Agent–Capability bindings, execution interface, and evidence-based verification system were implemented during this hackathon period.

Pre-existing ARES world-building materials and earlier ideas about multi-agent roles are disclosed as prior references and concepts. The previous Agentic Cinema prototype code was not copied as the foundation of the submitted KHALINOS system. The use of AI coding tools, including Codex, is also disclosed.

Built With

Share this project:

Updates