geni concept blog post concept

geni concept blog post concept.md

OpenGeni Is Getting Faster, Leaner, and More Efficient

10 October 2026 · OpenGeni Engineering

Fictional draft: This post and its benchmark results are illustrative and have not been published or verified by the OpenGeni team.

Today, we’re sharing the latest OpenGeni benchmark results—and the improvements are visible across the board.

Compared with our previous benchmark baseline, the new release delivers:

Benchmark	Improvement
Task-resolution speed	12% faster
Token consumption	8% lower
Tool calls per task	10% fewer

These numbers reflect a simple goal: help agents complete real work with less waiting, less unnecessary reasoning, and fewer interactions with external systems.

Why Efficiency Matters

OpenGeni is an open, self-hostable runtime for operating production AI agents. It provides the infrastructure surrounding an agent—including durable execution, isolated sandboxes, approvals, replayable sessions, audit trails, multi-tenancy, and metering—while allowing teams to bring their own models, tools, and agent logic. [7][15]

Production agents rarely complete their work in a single model call. They inspect context, invoke tools, wait for approvals, recover from failures, and continue across long-running sessions. Small inefficiencies compound quickly inside these workflows.

A redundant tool call is not merely an extra request. It can mean additional latency, token consumption, rate-limit pressure, infrastructure load, and another operation that must be observed and audited.

That is why this benchmark cycle focused on the complete path from intent to resolution—not just raw model response time.

What Improved

12% Faster Task Resolution

Agents now reach successful task completion 12% faster across our benchmark workloads.

The improvement comes from tightening the runtime path around agent execution: reducing avoidable orchestration overhead, making session state available more efficiently, and helping agents resume work without repeatedly reconstructing context.

For users, this means less time watching an agent “think about working” and more time seeing useful progress.

8% Lower Token Use

The latest benchmark run consumed 8% fewer tokens while maintaining the same task goals and success criteria.

We achieved this by reducing repetitive context, improving how relevant session information is assembled, and limiting unnecessary restatement of information already available in the execution history.

Lower token use is not only a cost improvement. Smaller, more focused contexts can make agent behavior easier to understand and reduce the chance that important instructions become buried in accumulated session data.

10% Fewer Tool Calls

Agents completed benchmark tasks with 10% fewer tool calls.

This improvement reflects better reuse of existing observations and more deliberate decisions about when another external action is actually necessary. Instead of repeatedly checking the same state, agents can make better use of durable session events and previously collected results.

Fewer tool calls mean:

• Less latency from external services.
• Lower exposure to third-party rate limits.
• Fewer redundant reads and writes.
• Cleaner audit trails.
• More predictable execution costs.
• A smaller operational surface to govern.

This is particularly important for OpenGeni because the runtime is designed around controlled, observable agent execution, including human approval gates, governed credentials, budget guards, and replayable histories. [7][13]

How We Benchmarked

We evaluated representative, multi-step agent workloads that combine reasoning, tool use, state transitions, and task completion.

To keep the comparison meaningful, the baseline and improved runtime used the same task definitions, success criteria, model configuration, tool interfaces, and execution environment. We then compared end-to-end resolution time, total model-token consumption, and the number of tool calls required to reach a successful outcome.

The reported figures represent aggregate improvements across the benchmark suite. Individual results will vary depending on the model, task complexity, tool latency, deployment configuration, and connected systems.

These benchmarks are not intended to claim that every task will become exactly 12% faster. They give us a consistent way to measure whether runtime changes make agent execution more efficient without sacrificing control or reliability.

What This Means for Teams

For a single session, these improvements may appear incremental. Across thousands of sessions, they become operationally significant.

A team running long-lived infrastructure, engineering, support, or internal-automation agents can expect faster feedback loops, lower model expenditure, fewer external API operations, and more concise execution histories.

Most importantly, the improvements do not come from weakening the controls around agent behavior. OpenGeni remains focused on durable sessions, sandboxed execution, explicit approvals, governed access, observability, and infrastructure that teams can operate within their own environment. [13][15]

What Comes Next

This benchmark release is another step toward making production agents feel less experimental and more dependable.

Our next optimization cycle will continue to focus on:

• Reducing unnecessary context growth in long-running sessions.
• Improving tool-selection precision.
• Shortening recovery time after interrupted runs.
• Making benchmark scenarios easier to reproduce.
• Expanding visibility into where agents spend time, tokens, and tool calls.

OpenGeni is open source and released under the Apache 2.0 license. If you are building agents that need to operate reliably beyond a chat window, explore the project, run the benchmarks in your own environment, and tell us where the runtime can improve next. [13][15]

Explore OpenGeni on GitHub

---

title: "Improved tool support: do more with less tool calls"
date: 2026-10-24
tags: [release, agents, tooling, codemode]
author: The OpenGeni Team

Improved tool support — do more with less tool calls

TL;DR — OpenGeni v0.14 reworks how the agent loop talks to tools. Instead of
one model round-trip per tool invocation, the agent can now express a whole plan
as a single executable program: batched calls, loops, conditionals, and
intermediate data handling all happen inside the sandbox. On our internal
evaluation suite this cut median tool calls per task from 17 → 4 and
end-to-end latency by 41%.

---

The problem with one-call-at-a-time

The classic agent loop is a conversation of tiny steps:

call list_repos → read 40 KB of JSON → call get_file → read → call
get_file again → read → summarise

Every arrow is a full inference pass. Every result — however irrelevant — is
pasted back into the context window. Tasks that are conceptually "go fetch
these twelve things and diff them" degrade into twelve serialized round-trips,
a bloated transcript, and a model that has forgotten the original goal by step
nine.

Three failure modes kept showing up in user reports:

1. Fan-out tax. Independent calls were executed sequentially because the
   protocol had no way to say "these don't depend on each other."
2. Context poisoning. Large intermediate payloads (build logs, directory
   listings, API dumps) crowded out the actual task.
3. Schema drift. Loosely-typed tool definitions meant the model guessed at
   arguments, failed validation, and burned another call retrying.

Code mode is now the default execution path

@opengeni/codemode has graduated from opt-in experiment to the default
strategy for capability-backed tools. Rather than emitting a JSON blob per call,
the agent emits TypeScript that runs against generated bindings inside the
sandboxed runtime:

// Emitted by the agent, executed once, inside the sandbox
const repos = await geni.github.listRepos({ org: "cloudgeni-ai" });

const stale = await Promise.all(
  repos
    .filter((r) => !r.archived)
    .map(async (r) => {
      const ci = await geni.github.getWorkflowRuns({ repo: r.name, limit: 1 });
      return { repo: r.name, status: ci?.conclusion ?? "none" };
    }),
);

// Only the distilled answer crosses back into context
return stale.filter((s) => s.status === "failure");

That is one tool call where the old loop needed twenty-nine. The 4 MB of
workflow JSON never touches the transcript — only the filtered result does.

Under the hood:

• declarations.ts emits fully-typed .d.ts bindings for every registered
  capability, so the model writes against real signatures instead of prose
  descriptions.
• environment.ts gained a deterministic execution budget: wall-clock, memory,
  and per-capability call ceilings, all enforced by the runtime rather than by
  hoping the model behaves.
• structured.ts handles the return-value contract, so a program's output is
  validated against the expected shape before it is handed back to the loop.
• artifacts.ts lets a program write large outputs directly to artifact storage
  and return a handle. Spreadsheets, documents, and presentations produced by the
  WASM artifact kernels are now referenced, not inlined.

Progressive tool disclosure

Registering 300 tools used to mean shipping 300 schemas in the system prompt.
@opengeni/capabilities now exposes a three-stage discovery flow that mirrors
how a developer actually explores an SDK:

Stage	What the agent sees	Typical token cost
search	Capability names + one-line summaries, ranked by relevance	~200 tokens
describe	Full input/output schema for the handful it selected	~1–2 K tokens
bind	Generated typed namespace injected into the sandbox	0 (lives in code, not prompt)

The practical effect: a workspace with 40 connectors now costs roughly the same
prompt overhead as a workspace with 4. Capability packs also declare
sideEffects: "read" | "write" | "destructive", and the runtime refuses to fold
a destructive call into an unattended batch without an explicit approval
handle.

Batching, retries, and idempotency

@opengeni/agent-proto picked up three protocol-level primitives that used to be
reimplemented (badly) in every integration:

• batch — a set of calls declared as independent; the scheduler fans them
  out with per-capability concurrency limits and rate-limit awareness.
• resume — long-running work returns a continuation token instead of
  blocking the loop, so a 20-minute deployment doesn't hold a turn hostage.
• idempotencyKey — writes carry a caller-supplied key, so a retried
  createIssue after a network blip produces one issue, not three.

ogtool grew matching CLI surface for local debugging:

ogtool caps search "workflow runs"
ogtool caps describe github.getWorkflowRuns
ogtool run ./plan.ts --trace --budget-calls 50

--trace prints the full call tree with timings, which pairs nicely with the
OpenTelemetry spans emitted from @opengeni/observability.

Numbers

Measured on evals/tool-heavy (180 tasks: repo triage, cloud inventory,
document generation, multi-service reconciliation), Oct 2026 build vs. the
v0.12 baseline:

Metric	v0.12	v0.14	Δ
Median tool calls / task	17	4	−76%
Median prompt tokens / task	118 K	41 K	−65%
p50 end-to-end latency	94 s	55 s	−41%
Task success rate	71%	84%	+13 pts
Invalid-argument retries	2.3 / task	0.2 / task	−91%

The success-rate jump surprised us. Fewer calls didn't just make things faster —
it made them more correct, because the model spent its attention on the task
instead of on re-reading its own scrollback.

Upgrading

bun add @opengeni/core@0.14 @opengeni/codemode@0.14 @opengeni/capabilities@0.14
bunx ogtool migrate tools --from 0.12

Breaking changes are listed in UPGRADE_LOG.md. The short version:

• registerTool() is deprecated in favour of defineCapability(), which
  requires an explicit sideEffects classification.
• The legacy one-call-per-turn executor is still available via
  strategy: "sequential" if you need bit-for-bit reproducibility of old runs.
• Custom tools must now declare output schemas; unknown returns are rejected
  at registration time rather than failing at runtime.

What's next

• Speculative capability loading — pre-binding the namespaces a task is
  likely to need, based on the opening prompt.
• Cross-turn program memoization — reusing a validated program when the same
  shape of request recurs.
• Capability packs from OpenAPI — generate typed bindings straight from a
  spec, no hand-written wrapper.

Issues and PRs welcome at github.com/Cloudgeni-ai/opengeni. If you have a
workload where the new executor makes things worse, we especially want that
trace.

---

title: "OpenGeni Test Drive Is Live: Run the Agent Harness Locally with Docker"
date: 2026-10-29
description: "Explore durable agent execution, isolated sandboxes, approvals, and observability from a complete OpenGeni environment running on your machine."
tags:

• OpenGeni
• AI agents
• Docker
• Open source
• Developer tools

---

OpenGeni Test Drive Is Live

29 October 2026

Today, we are launching OpenGeni Test Drive: a fast, self-contained way to run the OpenGeni cloud harness locally using Docker.

No cloud account. No shared environment. No lengthy infrastructure setup.

Clone the repository, start the Docker stack, and explore how production-grade agents behave when execution becomes durable, observable, and controllable.

Bring your agent, model, and tools. OpenGeni provides the infrastructure around them.

From Agent Demo to Agent System

Building an agent that completes a prompt is relatively easy.

Building one that can run for hours, survive interruptions, request approval, use credentials safely, recover from failure, and leave behind a complete audit trail is a different problem.

That is the problem OpenGeni is designed to solve.

OpenGeni sits between your agent and the infrastructure it needs to operate. It provides a production harness for long-running agent workloads without dictating which model, framework, or tools you use.

With Test Drive, you can explore that architecture entirely on your local machine.

Start Locally with Docker

Make sure Docker and Docker Compose are available, then clone OpenGeni:

git clone https://github.com/Cloudgeni-ai/opengeni.git
cd opengeni

Create your local environment configuration:

cp .env.example .env

Add the model credentials you want to use, then start the Test Drive stack:

docker compose up --build

Once the containers are ready, open the local OpenGeni interface in your browser:

http://localhost:3000

The complete harness remains on your machine, including the control plane, event history, workers, sandbox infrastructure, and local development services.

To stop the environment:

docker compose down

To remove the local Test Drive data and begin again from an empty environment:

docker compose down --volumes

What You Can Explore

Test Drive is not a static product tour. It is a working OpenGeni environment where you can create sessions, observe execution, interrupt agents, and inspect what happened.

Durable sessions

Agent runs are represented as durable sessions rather than disposable API requests.

You can follow a session over time, inspect its event history, and understand how execution progressed—even when work spans multiple steps or encounters a failure.

Human approvals

Pause an agent before a sensitive operation and require a person to approve, reject, or redirect the next action.

This allows teams to introduce automation gradually instead of choosing between fully manual workflows and unrestricted autonomy.

Isolated execution

Run agent tasks inside isolated sandboxes rather than giving an agent unrestricted access to the host system.

The sandbox becomes an explicit execution boundary for tools, code, files, and dependencies.

Interrupt and steer

Long-running agents should not become black boxes after they start.

With OpenGeni, a session can be observed, interrupted, and steered while it is running. Operators remain part of the control loop without having to restart the entire workflow.

Replayable history

Inspect the sequence of events behind an agent run instead of relying only on its final answer.

Replayable histories make debugging easier and provide the operational context needed to understand why an agent made a particular decision.

Audit trails

See which tools were invoked, when approval was requested, what a person authorized, and how the session changed over time.

This creates a clearer path from experimental agent behavior to governed production automation.

A Smaller Distance to the First Run

Before Test Drive, evaluating an agent runtime often meant reading architecture documents, assembling infrastructure, and mentally connecting several moving parts.

We wanted the first experience to be more immediate.

Test Drive packages those moving parts into a reproducible Docker environment. It is designed for engineers who want to examine the system directly:

• Run an agent and inspect every event.
• Stop a session midway through execution.
• Add an approval boundary around a sensitive tool.
• Restart a component and observe recovery.
• Connect your own model and agent implementation.
• Tear everything down when the experiment is complete.

The goal is not to hide the architecture. The goal is to make it easier to experience.

Bring Your Own Agent

OpenGeni is not an agent framework and does not require you to rewrite your agent around a proprietary abstraction.

Bring the agent you already have.

Bring the models and tools that fit your workload.

OpenGeni supplies the operational layer around them: durable execution, sandboxing, approvals, governed access, observability, and control.

That separation is important. Agent logic will continue to evolve quickly, while requirements such as isolation, auditability, recovery, and human oversight remain foundational.

Local First, Production Ready

A local Test Drive is intentionally small, but the concepts it demonstrates are production concerns.

The same session that looks like a convenient development abstraction locally becomes an operational boundary in production. The same approval step becomes a change-control mechanism. The same event stream becomes a source for debugging, compliance, and incident analysis.

Running locally lets teams examine those ideas before committing infrastructure or exposing real systems.

It is a place to ask practical questions:

• What should this agent be allowed to do automatically?
• Which actions require human approval?
• What evidence should be retained?
• How should an interrupted session recover?
• Where should credentials become available?
• Can we explain what the agent did after the run finishes?

Those questions are difficult to answer from a diagram. They become much clearer when the harness is running in front of you.

Take the Test Drive

OpenGeni Test Drive is available now.

Clone the repository, launch the Docker environment, and put your agent inside a harness built for work that lasts longer than a single request.

git clone https://github.com/Cloudgeni-ai/opengeni.git
cd opengeni
cp .env.example .env
docker compose up --build

Explore the project on GitHub:

github.com/Cloudgeni-ai/opengeni

---

OpenGeni is open source and self-hostable. This article is a fictional launch-post concept for a proposed Test Drive experience dated 29 October 2026.