How Felixfusion is built.

Overview

Felixfusion is a multi-agent runtime for long-running, document-heavy work. The unit of execution is an agent worker that holds state across weeks, consults a shared ingestion layer for source material, and routes every externally-visible artifact through a human approval gate.

Most AI systems today are optimized for the chat loop. Our engine is optimized for the opposite: operations that take weeks, involve thousands of pages of regulatory text, and produce artifacts that a human will sign and send to a counterparty. Every design decision below follows from that distinction.

Data-agnostic ingestion

A single tender pack can run two thousand pages. A grid cluster study can run five thousand. The volume is not the hard part. The hard part is that the structure is idiosyncratic, the cross-references are human-readable only, and the source format varies from CSV to scanned PDF to image-embedded Excel.

Our ingestion layer parses each source format into a normalized schema that downstream agents can query without reasoning about the original wrapper. We preserve pagination, table boundaries, and footnote anchors as first-class fields so that any claim an agent later makes can be traced to a specific page, table, and row.

Documents never become opaque embeddings alone. Every piece of structured extraction keeps a bidirectional link back to the source. Ask any agent why it made a claim and it returns the source passage, not a plausible-looking paraphrase.

Stateful orchestration

A real engagement does not finish in a chat turn. A bid response runs for 30 to 60 days. An interconnection DD pack runs for 9 to 12. The engine has to keep state the entire time, resume cleanly after interruptions, and hand off cleanly between specialist agents.

We model work as a persistent task graph. Each node is a step with explicit inputs, outputs, and invariants. The runtime checkpoints after every step. When an agent worker restarts (because of a deploy, a network blip, or a human override) it reads the last known checkpoint and continues exactly where it was. No lost context, no duplicate work.

Handoffs between agents are typed. A research agent passing partial findings to a writing agent passes a structured object, not a prompt. The writing agent's own prompt is generated from the structured input, not inherited. This removes the failure mode where instructions drift across conversational turns.

Human-in-the-loop governance

Nothing an agent produces leaves the system without a human approval. Every external artifact (a DD pack, a bid, a compliance letter) is generated as a draft, flagged for review, and held until an authorized reviewer signs off.

The review interface shows the draft alongside the source trail. A reviewer can open any claim in the draft and see exactly which pages, tables, and agent decisions produced it. Approving a draft is a signed event. Rejecting routes it back to the generating agent with structured feedback, not free text.

The full history of every generation, revision, and approval is written to an append-only audit log. The log is exportable on request. We are designing toward the evidence standard a regulated buyer brings to an audit; we are not at the point of a third-party attestation yet.

Infrastructure

Agent workers are Python processes running on a managed Kubernetes cluster. State lives in a managed PostgreSQL instance with point-in-time recovery. Parsed source documents live in object storage behind a content-addressable hash. Model calls go through a thin provider-agnostic gateway so model choice is a deployment configuration, not a code change.

Region is fixed at deploy time. Today we operate in us-east. EU residency is on the roadmap and will ship ahead of the first EU pilot.

Security posture

We are a seed-stage company. We do not hold SOC 2, ISO 27001, or any other third-party attestation today. The items below describe what the engine is designed to enforce, not what is audited.

Each pilot runs in an isolated execution context with no shared database schema, no shared object-storage bucket, and no shared model context window. Transport is TLS 1.2 or higher. At rest we use AES-256 with KMS-managed keys; customer-managed keys are supported in scoped deployments.

Our 2027 roadmap includes formal SOC 2 Type I work. Until then, we stand up pilot engagements under a mutual NDA and are willing to walk diligence teams through our controls on a call.

Deployment models

Today we offer two deployment targets. The first is our managed environment, where the engine runs in Felixfusion-operated infrastructure and each engagement is isolated at the workflow level. This is the faster path from first call to first artifact and is the right fit for most pilots.

The second is a customer-VPC deployment, where the engine runs in a customer-owned AWS or Azure account. We operate it, the customer owns the keys and the storage. This is the option buyers reach for when a security review requires data never to cross a customer boundary.

Air-gapped on-premises is a configuration we have mapped out but do not offer as a standard package. If your procurement requires it, reach out through the contact page.

Typical engagement

Every engagement starts as a scoped pilot. We agree on one workflow (a single DD pack, a single tender response) and one success criterion. A pilot typically runs four to six weeks and produces a finished artifact the customer's own team reviews alongside their existing process.

Commercials are discussed during the pilot phase and depend on deployment model and workflow volume. We do not publish a price list at this stage.

We do not offer self-service onboarding. Every engagement has a named account engineer on our side. For serious buyers this is usually a feature.