SEIF Docs

SEIF ↔ OpenBot portability

A SEIF project and an OpenBot server describe the same thing from two sides: a team of agents that do bounded work and hand it to each other. OpenBot is a local-first desktop workspace (macOS, Windows and Linux); SEIF is the web product that manages, versions, engineers and proves the context those agents receive. Portability lets a customer who chooses OpenBot keep everything SEIF offers — management, versioning, context engineering and audit — instead of losing it.

This is Layer 1: moving a whole project across the boundary as plain data (a file you download or upload). It needs no local bridge and assumes no operating system. The optional local bridge remains for running the team on your own machine; it is not required for portability.

What you can do

  • Take a SEIF project to OpenBot. Export the team as a pack of separate OpenBot agents — one folder per member, with its instructions, the knowledge areas it reads, and the team's flows and routines written in plain language.
  • Bring an OpenBot project into SEIF. Import our pack, or a plain OpenBot export (a ZIP or a folder of agents), and SEIF turns it into a file-native project versioned in git, with one agent per member.
  • Start a new project from an OpenBot import. On the home screen, New project → Import from OpenBot.
  • Audit the context used in OpenBot. Every hand-off SEIF delivers records the exact context it sent — its size, an estimated token count, a content digest and the knowledge areas selected — so OpenBot work stays auditable in SEIF even though the agent runs elsewhere.

The interchange package: seif.openbot-pack.v1

The pack is a SEIF-authored, documented format — not a copy of OpenBot's own on-disk files. OpenBot is PolyForm Noncommercial and its internal shape is undocumented, so SEIF never embeds or depends on it. The pack is a map of relative path → text:

openbot-pack.json          # manifest: agents, flows, routines, notes (the audit record)
README.md                  # how to recreate the agents and routines in OpenBot, and the audit boundary
agents/<member>/AGENT.md   # one standalone OpenBot agent per SEIF member: instructions, areas, boundary
agents/<member>/context.json  # machine-readable: abilities, areas, the mapped OpenBot agent id (if any)
shared/knowledge/**/*.md   # the knowledge areas the agents read, copied verbatim (provenance stays in the text)
shared/policies/**/*.md

Export

  • Web: Conexões → OpenBot → Baixar pacote para o OpenBot (a ZIP download). Works on any OS.
  • CLI: the engine command openbotExport ({ projectDir, agentMap? }) returns { pack: { format, name, files, manifest } }.
  • HTTP: GET /api/projects/:id/openbot/pack streams the pack as a ZIP (application/zip).

The export reads the project's team.yaml (members, flows, routines) and each member's agent files (agents/<id>/AGENT.md, its objective instructions and context.yaml). The OpenBot agent chosen for each member in Conexões → OpenBot is carried in context.json so the pack records it.

Import

  • Web: home → New project (a business) → Importar do OpenBot, then pick a ZIP or the agents folder.
  • CLI: the engine command openbotImport ({ pack, name? }) returns { project: { format: 'seif.cloud-project.v1', name, files, report } }.
  • HTTP: POST /api/projects/import/openbot with { format?, name?, files } creates a new, versioned project and returns { project, report }.

Import accepts two shapes:

  1. Our pack (openbot-pack.json present): members, flows, routines and shared knowledge are restored directly.
  2. A plain OpenBot export (any ZIP/folder): each folder that contains an instruction-like file (AGENT.md, AGENTS.md, CLAUDE.md, README.md, prompt, system, instructions) becomes one agent. Other Markdown becomes shared knowledge in an imported area. Anything not recognised is recorded in report.unrecognised, never invented.

The result is a file-native SEIF project: seif.yaml, one agents/<id>/ per member, knowledge/, and team.yaml. It loads cleanly (seif doctor passes) and is versioned in git like any project.

Audit of the context used in OpenBot (Layer 2, minimal)

When SEIF hands work to an OpenBot agent, it records — in the hand-off packet and in the team state — what it delivered:

"context": { "chars": 5848, "estimatedTokens": 1462, "digest": "sha256:…", "areas": ["company","sales"], "messages": 1 }

Conexões → OpenBot → Últimos handoffs · evidência shows, per hand-off: the member, the OpenBot agent that ran it, delivery/hand-back, observed duration, and the context delivered (estimated tokens, number of areas, digest).

Honesty about limits: time, agent and the context SEIF delivered are observed. The model's token usage and OpenBot's internal tools are not reported when OpenBot does not provide them — SEIF never invents cost, and never shows US$0 as if it were a measured cost.

The boundary

A chat typed directly inside OpenBot does not pass through SEIF and cannot be audited, tracked, associated with project context or priced by SEIF. For traceability, start the work in SEIF (Hoje/Equipe) and let it hand off; the export pack and both UIs state this explicitly.

Limits and safety

  • Packages are bounded: at most 200 files and 10 MiB of text; each file at most 1 MiB.
  • Credentials, API keys, message history and connected data are never exported; set them up again where they are used.
  • Import refuses unsafe paths and any file that contains a credential.

Delivery observation (Layer 2)

The optional local bridge now records a minimized, durable delivery trail for work started in SEIF. It records only transitions the bridge itself observes, keeps a private atomic outbox for retries, and exposes the resulting projection under Conexões → OpenBot. HTTP 200/202 from an OpenBot webhook means the endpoint accepted delivery, not that OpenBot executed the work. The bridge does not claim model tokens, cost, tool use, response content, or context consumption. See OpenBot delivery observation for the receipt contract, idempotency behavior and limits.