Geulbat

agents loop, code mode, third party

Comment

Inspiration

Most AI development tools invoke one tool at a time. The model requests an operation, reads the result, and only then decides what to call next. As tasks grow more complex, intermediate data passes through the model's context again and again, driving up both latency and token usage.

The final output, too, is often confined to prose or terminal text.

We wanted to explore a different approach:

What if an AI could write a small program that orchestrates multiple tools?

What if it could present the result as a live, interactive visual directly inside the conversation?

These questions led to Geulbat's two defining capabilities: Programmatic Tool Calling (PTC) and the live visualize tool.

We also wanted Geulbat to be a long-lived workspace rather than a disposable chat window—one where agents can use real development tools, coordinate parallel work, preserve their history, and keep going beyond a single model context window.

## What it does

### Programmatic Tool Calling

PTC is Geulbat's primary capability.

Rather than invoking every tool separately, the model can write and execute JavaScript—or erasable TypeScript—inside an isolated Docker environment. Generated Geulbat SDK wrappers give that program access to admitted capabilities such as file reading, search, and memory retrieval.

The model can combine those capabilities with ordinary programming constructs:

  • loops and conditional branches
  • local filtering and data transformation
  • repeated operations over many inputs
  • aggregation of results from multiple tools
  • selective return of only the information it needs

Intermediate values can stay inside the execution environment instead of being serialized into the conversation over and over.

Conceptually, a conventional sequence may require:

$$ T_{\text{serial}} \approx n\left(T_{\text{model}} + T_{\text{tool}}\right) $$

PTC aims to cut those model round trips by moving orchestration into a single program:

$$ T_{\text{PTC}} \approx T_{\text{model}} + T_{\text{program}}(n) $$

Long-running executions rely on separate exec and wait operations. A stable cell identifier lets the agent continue useful work and retrieve the result later, rather than blocking the entire interaction.

### Live, interactive visualization

The visualize tool lets the model create an SVG- or HTML-based diagram, chart, mockup, or lightweight interactive widget directly inside the current conversation.

The visual does not simply appear once generation finishes. Tool arguments stream to the client, so the widget can render progressively as its markup arrives. It runs inside a sandboxed inline frame and can use a sendPrompt bridge to turn user interaction into a follow-up request.

Temporary explanatory visuals stay inside the conversation. Documents or applications that need to be reopened, edited, or exported use Geulbat's separate persistent artifact system.

### Open CLI execution

Geulbat is not confined to a fixed catalog of predefined tools.

Through exec_command, the agent can invoke command-line programs installed in the working environment—including Git, compilers, type checkers, linters, test runners, search utilities, and repository-specific scripts.

This lets Geulbat work with an unfamiliar repository without a dedicated wrapper for every local command. Interactive or long-running processes can retain a session handle and receive further input.

Its execution surface combines three complementary layers:

$$ \text{Execution Surface} = \text{Typed Tools} + \text{Open CLI} + \text{Programmatic Tool Calling} $$

Typed tools provide stable, validated operations. Open CLI execution provides access to the real development environment under approval and sandbox policies. PTC provides programmable composition inside an isolated runtime.

### Recursive parallel subagents

Geulbat can split a larger task into independent pieces and launch explorer or worker subagents in parallel. Child agents may in turn launch nested helper agents when further decomposition is useful.

The current implementation provides:

  • same-round parallel child launches
  • stable child-run handles
  • non-blocking progress snapshots
  • explicit wait, stop, and follow-up-input operations
  • visible child lifecycle and progress state
  • provider and model selections pinned before child execution
  • recursive routing continuity across descendants

### Long-lived context

Geulbat stores conversations as append-only transcripts and adds compaction checkpoints without deleting the original entries.

It measures context consumption, displays it in the interface, and can compact the active context before a provider's usable threshold is exceeded. Because providers may have different context limits, Geulbat also warns the user when switching models would require compaction.

## How we built it

Geulbat is implemented as a strict TypeScript monorepo.

The daemon owns:

  • model and provider communication
  • tool execution and approval boundaries
  • PTC Docker runtimes and retained execution cells
  • subagent state and lifecycle
  • transcript persistence and compaction
  • artifact storage and runtime bridges

A React-based web shell renders streaming conversations, progressively generated visual widgets, persistent artifacts, context usage, and subagent progress.

A shared protocol package defines the events and data contracts exchanged between the daemon and the client. Values crossing a process, network, tool, file, or provider boundary begin as unknown and are validated before becoming trusted internal types.

PTC code runs inside an isolated Docker environment. Host capabilities are available only through admitted callback boundaries and generated SDK projections. Raw host CLI execution remains a separate, approval-aware process path rather than being silently folded into PTC.

The visualization system reuses Geulbat's sandboxed artifact runtime while keeping temporary widgets inline and visually integrated with the conversation.

## Challenges we ran into

One of our biggest challenges was making programmable execution powerful without turning it into unrestricted host access. We had to draw clear lines between:

  • sandboxed PTC execution
  • admitted tool callbacks
  • raw host CLI processes
  • user approval policy
  • persistent output ownership

Progressive visualization was another hard problem. Incomplete JSON and markup arrive while the model is still generating them. The client must recover useful partial content, update the frame safely, and avoid repeatedly restarting the widget.

Long-running PTC cells introduced lifecycle problems involving queued work, disconnections, delayed results, process termination, daemon restarts, and results that must stay retrievable without blocking unrelated executions.

Provider context limits created yet another challenge. A conversation that fits inside one provider's context may exceed another's. Switching providers therefore cannot be treated as a simple model-name change; it may require an explicit compaction decision.

Recursive agents also demand careful governance. Nested execution is implemented, but we do not want to claim that arbitrary recursion is already fully governed. We want to halt unproductive recursive branches without imposing an arbitrary depth limit or hiding orchestration inside a private queue.

## Accomplishments that we're proud of

We are especially proud that PTC is more than a prototype or a code-generation demo. It is wired to a real sandbox runtime, generated tool SDKs, host callback admission, retained execution cells, and explicit exec/wait lifecycle handling.

We are equally proud of the visualize experience. The model can produce a visual that appears progressively within the same conversational turn, and the user can interact with it without ever leaving the workspace.

Another accomplishment is Geulbat's layered execution model. Stable typed tools, real CLI access, and programmatic tool composition are all available together without collapsing their security boundaries.

Our recursive subagent system supports visible same-round parallel launches, nested helpers, stable handles, progress inspection, continuation, and explicit termination. The parent can keep doing independent work instead of blocking whenever a child is running.

Finally, our append-only transcript and compaction design preserves the original conversation while letting the active model context continue beyond a single context window.

The combination of PTC, open CLI execution, live inline visualization, recursive agents, persistent artifacts, and long-lived context is the accomplishment we are most proud of.

## What we learned

We learned that the number of available tools matters less than how those tools can be composed. PTC turns individual capabilities into programmable building blocks.

We also learned that visualization is not merely decorative. When users can immediately inspect and interact with an AI-generated structure, the conversation becomes a working interface rather than a stream of text.

Typed tools and raw CLI access are both necessary. Typed tools provide reliable contracts for common operations, while CLI execution lets the system adapt to real repositories and their environment-specific workflows.

Long-lived memory is not only a summarization problem. It is also a problem of ownership, persistence, provider compatibility, recovery, and making compaction visible to the user.

Finally, we learned to distinguish capability from governance. Supporting recursive agents is not the same as proving that recursive execution is safely bounded. Clearly separating what is implemented from what remains future work is essential to building a system users can trust.

## What's next for Geulbat

Our next major step is progress-backed governance for recursive subagents:

  • normalized execution grants
  • renewable run leases
  • evidence-backed structural checkpoints
  • pluggable, domain-specific ProgressOracle evaluation
  • deterministic cleanup of stalled branches and their descendants

The goal is to let productive branches continue without a fixed recursion-depth limit, while reclaiming branches that consume resources without showing meaningful progress.

We also plan to:

  • expand the generated PTC SDK and its safely admitted capabilities
  • connect PTC outputs more deeply with persistent artifacts
  • allow useful temporary visualizations to be promoted into reusable artifacts
  • improve recovery for long-running cells and interrupted sessions
  • refine provider transitions and the compaction UX
  • benchmark PTC's effect on latency, token usage, and model round trips using representative workloads

Ultimately, we want Geulbat to become a workspace where an AI can program its tools, use the real development environment, coordinate visible parallel agents, and communicate through interactive results—not only text

Built With

Share this project:

Updates