How the Inverted Firm Is Built
Work, authority, evidence and human finality
A shared production graph, explicit authority and a version-bound evidence ledger. How the operating thesis becomes a firm, and what still has to be built.
7. The firm is a shared production graph
Infra One is building the human-and-agent production layer for regulated financial operations. Its initial wedge is fund administration.
Fund administration today is often organised around people handing work to people: an administrator prepares, a manager reviews, a partner signs, and evidence is scattered across spreadsheets, inboxes, shared drives and individual memory. Software may help each actor, but it rarely becomes the durable location of work, authority and evidence.
Infra One reorganises the work around a shared production graph.
A production unit can be a NAV, reconciliation, filing, KYC refresh, capital-call notice, distribution, investor communication, audit request, handover or software change. It has:
- A purpose, scope and acceptance criteria.
- A state and explicit progression path.
- Dependencies on data, documents, rules, approvals and upstream work.
- A claimant and attributed production history.
- Defined permissions for people, agents and services.
- Automated validations, exceptions, reviewer findings and decisions.
- A finality gate.
The defining proposition is simple:
Humans and agents are first-class participants in the same firm.
Both can receive work, claim it, produce an output, hand it off, raise an exception and be named in the record. Their permissions differ. A qualified person may decide a material exception and approve a regulated outcome; an agent may not. But the work does not happen in a human system with agents on the side. It happens in one production graph.
8. What exists today
Infra One already operates the core orchestration primitives in its own engineering environment through Harness. Harness began as an issue tracker and developed into an operating layer for work that must be coordinated, evidenced and reviewed.
In the current engineering instance:
- Every material unit of work begins as an issue with scope, acceptance criteria and dependencies.
- A model may classify or explain a new issue, but people retain authority over approval-state transitions.
- A human or agent can claim approved work through controlled assignment.
- An approved task can be implemented by an agent on a fresh branch.
- The platform, not the agent, performs privileged workflow actions such as opening a pull request.
- Review findings, verdicts and final decisions are stored server-side against the exact commit under review.
- A changed commit creates a new identity, requiring review validity to be reconsidered according to workflow rules.
- Closure depends on configured evidence and gates, not on an actor’s assertion that the work is complete.
This is live evidence for the work graph, controlled claiming, attributed execution, review ledger and workflow analytics. It is not a claim that fund production is already automated or that an engineering workflow automatically satisfies the full requirements of a regulated financial-services control framework.
An internal August engineering observation illustrates the model: a screenshot and a small number of prompts led to eleven reviewed, merged and closed pull requests over roughly 78 hours, the removal of ten legacy modules and a guard intended to prevent their reintroduction. The meaningful point is not the count. It is that scope, dependencies, tests, review verdicts, merge state and closure were durable system state rather than an unstructured transcript or an individual’s memory.
9. The architecture
A regulated production implementation requires more than a model and a task queue. It needs distinct layers that make work, authority, evidence and finality explicit.
| Layer | What it does | Plain-English description |
|---|---|---|
| Work graph | Represents work units, dependencies, owners, deadlines, states and escalations | The live map of everything that must happen to complete a fund operation |
| Policy and authorization | Defines what each human, agent or service may read, produce, change, approve or release | The rulebook for who and what may do which part of the work |
| Production and validation | Combines deterministic services, structured data processing and bounded agents | The machinery that performs recurring work and checks it as it goes |
| Evidence ledger | Binds inputs, versions, checks, findings, overrides and approvals to the artifact | The durable record that shows what happened and why a result was accepted |
| Human finality gate | Requires an authorized professional decision where required | The point at which qualified human judgment makes the result real |
Work graph
For a NAV, the graph may include source-document intake, data extraction, cash and position reconciliation, valuation inputs, ledger posting, allocation logic, variance analysis, exception resolution, reviewer queries, approval and distribution. A filing may depend on calculations, document versions, disclosure checks, approvals and controlled submission.
The graph prevents a dangerous shortcut: treating a plausible final document as evidence that the preceding work happened correctly. Finality is the result of a completed chain of evidence, not fluent output.
Authority boundaries
The relevant question is not whether an agent is “autonomous.” It is what authority it holds, on which task, over which data, in which workflow state and with what consequences.
An agent may be allowed to claim a policy-approved task, read task-scoped inputs, produce a draft or proposed calculation, run an approved validation, request information, raise an exception or propose a handoff. It should not be able to grant itself authority, redefine acceptance criteria, self-approve, self-sign, override a failed control without authorized human action, obtain standing privileged credentials or edit its own audit record.
The practical implementation can include least-privilege access, short-lived scoped authorization, platform-mediated privileged actions, separation between production and release authority, outbound controls and immutable server-side audit events.
Production and validation
Infra One combines deterministic logic, structured data transformations and model-assisted agents. They are not one opaque “AI layer.”
Deterministic logic handles calculations, validations, routing rules and reconciliations where inputs and rules are defined. Models assist with unstructured extraction, classification, retrieval, drafting, explanation and routing. Qualified humans address novel facts, ambiguous terms, materiality, valuation judgment, policy interpretation and decisions reserved to accountable professionals.
Every material artifact should retain enough provenance to reconstruct production: source versions, data lineage, ruleset and policy versions, validation results, relevant model or service identity, execution time and actor identity.
Evidence ledger and finality
Every output receives a version identity, such as a content hash combined with lineage metadata. Review findings, validation outcomes, exceptions and approvals bind to that exact version.
The central rule is:
A material change produces a new version. A prior approval applies only to the version approved, unless an explicit policy records why the change is immaterial.
The ledger records artifact version history; inputs and provenance; validation evidence; reviewer findings; resolution and dismissal reasoning; authority evaluations; approvals; state changes; and retention and access events relevant to the record.
The human finality gate is not a ceremonial signature. It is an authorized decision on a specific evidence-complete version. The platform should compute whether the evidence conditions for finality are satisfied; the accountable human makes the professional judgment that only they are entitled to make.
10. Measuring the firm
The inversion is an operating-economic hypothesis. It should be measured in ways that reveal genuine leverage rather than hidden manual work, under-resourced review or transferred client risk.
| Metric | Working definition | Guardrail |
|---|---|---|
| Cost per completed production unit | Loaded human time, attributable model/compute spend and platform/operations cost per unit | Segment by complexity, jurisdiction, asset class, fund structure and reporting cycle |
| System-performed share | Share of workflow steps completed by deterministic or agentic services without discretionary human execution | Separate system completion from mere model suggestion; mandatory sign-off is not a failure |
| Human intervention rate | Human interventions beyond mandatory controls per completed unit | Classify as required control, material judgment, source-data remediation, exception or capability gap |
| Review quality | Findings, dismissals, overrides, approval time and post-approval defects by reviewer and risk class | High reviewer throughput is a risk signal unless quality indicators support it |
| Reuse rate | Share of rules, validations and workflows reused across comparable work | Do not mislabel bespoke client work as standardisation |
The metrics become the engineering roadmap. Every manual correction, escalation and reviewer intervention is a signal. Sorted by frequency, risk and cost, those signals identify which rule, test, validation or workflow should be built next.
11. Failure is designed for
The main risk is not an agent making an obvious error. Obvious errors are often caught. The more dangerous failure is a plausible error that propagates, escapes a weak review or cannot be reconstructed later.
| Failure mode | Example | Design response |
|---|---|---|
| Incorrect source data | A statement is incomplete, stale or incorrectly parsed | Data lineage, completeness checks, source-to-output reconciliation and exception routing |
| Ruleset or policy drift | A fund document, tax rule or regulatory requirement changes while old logic remains active | Versioned policies, change control, effective dates, regression suites and named policy ownership |
| Model error | A model invents a rationale or misclassifies a document | Bounded use cases, structured outputs, retrieval controls, independent validation and escalation thresholds |
| Correlated system failure | A faulty rule affects many funds | Tenant-aware isolation, impact analysis, canary release, rollback and targeted reprocessing |
| Separation-of-duties failure | One actor changes a rule, produces output and approves it | Segregated roles, independent approval paths and auditable authority checks |
| Privilege failure | An agent accesses more data or performs a broader external action than permitted | Least privilege, scoped authorization, platform-mediated actions and immutable audit events |
| Rubber-stamping | A reviewer approves high-volume output without meaningful scrutiny | Workload analytics, risk-based QA, reviewer-quality indicators, escalation and accountability |
| Non-reproducible history | The basis for a prior conclusion cannot be reconstructed | Retained inputs, versioned rules, execution provenance and controlled reference corpora |
| Confidentiality or residency breach | Sensitive investor data is processed or retained contrary to applicable requirements | Data classification, vendor and model governance, access controls, encryption and retention policy |
The objective is not to claim that the system cannot fail. It is to make failure observable, attributable, recoverable and systematically less likely over time.
12. Build sequence
Fund production is not yet running through Harness. The path from live engineering primitives to regulated production is a build sequence and must be proved in production.
- Define the production units. Represent NAVs, reconciliations, filings, KYC refreshes, capital calls, distributions, audit requests and handovers as explicit workflows.
- Map authority and obligations. Identify, for each entity, jurisdiction and service, what may be automated, what must be reviewed, who may decide, and what recordkeeping and outsourcing constraints apply.
- Generalise the evidence ledger. Bind all material financial artifacts, validations, exceptions and approvals to a versioned identity.
- Automate bounded tasks first. Begin with deterministic, high-volume and evidence-rich work: data checks, extraction with review, reconciliations, completeness controls, exception routing and controlled calculations.
- Instrument intervention. Record every human correction, escalation and override; classify the cause and feed the product roadmap from observed work.
- Validate the gate. Measure review capacity, reviewer findings, re-open rates, overrides and post-approval defects before increasing agent throughput.
- Publish evidence, not slogans. Report production metrics only once there is a defined baseline and enough segmentation to make comparison meaningful.
The first meaningful proof point is not an agent producing a plausible output. It is a live regulated workflow with traceable inputs, versioned rules, visible validation, attributable human-and-agent contributions, accountable approval and a reproducible audit trail.
From thesis to assumptions
Put the ideas to the test.
Explore the investment case, or change the assumptions in the illustrative economics model.