Finkkle Igno · Architecture

Finkkle Igno Agentic System

Igno is a model-directed agent workspace: the model can choose the tools it needs, use several tools in one turn, observe their results, and continue until the requested outcome is complete.

Canonical runtime reference

One interaction, many tools

Every ordinary Igno turn uses the same bounded model/tool loop: the model receives the available tool manifest, emits structured calls, receives structured results, and reassesses the request. Independent calls can run in parallel; dependent calls run in order.

user turn → context → model tool calls → tool results → model reassessment → answer, approval, task, or automation

Igno does not require command prefixes, special formatting, or a client-side keyword detector to decide that a tool is needed. The server still validates schemas, ownership, permissions, limits, cancellation, and idempotency.

Tool contract

Every model-visible capability has one descriptor covering its input and output schema, read/write/execute class, authentication, approval policy, timeout, retries, rate limits, idempotency, cancellation, caching, provenance, and resource owner.

Web, news, knowledge, image, video, shopping, compute, Gmail, Calendar, Sandbox, visual artifacts, plugins, Tasks, and Automations are capabilities in this system. New capabilities must use the registry and common executor instead of adding another route-specific router.

Playground and Sandbox

Playground/Sandbox is an ordinary agent tool. The model can select it for commands, file edits, tests, builds, analysis, or artifact creation. It returns a durable task/workspace result through the same activity stream as every other tool.

Sandbox “full access” means full access to the authorized isolated workspace. Host files, credentials, unrestricted network access, and arbitrary privileges remain outside the workspace boundary.

Side effects and approval

Read-only tools run automatically. Externally visible writes, such as sending mail or creating a calendar event, pause for an expiring confirmation. Approval is enforced by the executor, not by a prompt instruction. Approved operations use idempotency protection so retries cannot duplicate an external action.

Tasks and Automations

Tasks are durable agent runs attached to a conversation. Automations are durable agent runs triggered by a schedule or supported event. Both use the same model and tool contracts as an interactive turn.

The model can create an Automation with a structured objective and schedule. Recurring intervals shorter than one hour are rejected server-side. Each run receives the saved objective, current account context, prior run state, and the Automation approval policy.

Runtime events

The UI consumes one activity vocabulary for model turns, tool calls, progress, failures, approvals, completion, cancellation, and durable continuation. Every request records an owner, screen, reason, request ID, cache state, duration, and status.

Adding a tool

  1. Add one descriptor to the capability registry.
  2. Implement one server-owned bounded executor.
  3. Declare authentication, approval, retry, timeout, idempotency, and resource behavior.
  4. Return structured results and provenance.
  5. Add runtime, integration, failure, duplicate-call, and browser-flow tests.
  6. Update the canonical agent documentation.

Do not add a new regex router, special chat branch, client-side executor, or independent polling loop for a new capability.

Verification

Agent changes must verify multi-tool turns, Sandbox durability, Gmail and Calendar reads, approval and exactly-once external writes, the one-hour Automation limit, cancellation, reload, offline behavior, hidden-screen gating, and deployed bootstrap and health checks.

The engineering source for this page is docs/igno-agentic-system.md in the repository.