• 

• 

• 

• 

• 

• 

• 

• 

Verletica

Inspiration

Verletica began with a question that is more difficult than “How do we make an AI agent useful?” The harder question is: How do we let several AI agents act inside a real organization without turning permissions, private context and accountability into assumptions hidden inside prompts?

A real business is not a collection of independent chat sessions. It has departments, changing staffing, confidential relationships, informal processes, financial commitments and work that continues after a person closes a browser tab. Two agents can each do something reasonable and still create a harmful combined outcome. An agent can also be technically capable of answering a question while being unauthorized to see the information needed to answer it.

That led to the central design idea behind Verletica: autonomous agents need an operating environment that understands identity, authority, memory, commitments, collisions and time. The name comes from Verlet integration, a method used in physics simulations to evolve interacting bodies while satisfying constraints. The analogy is deliberate. Verletica is designed for many human and machine principals to move independently while remaining inside shared organizational constraints. 1

This is our entry for The Fortified Enterprise Fleet track. Its hooks — enforced identity and authority, memory isolation, audited writes, human decision points — are exactly the properties Verletica treats as mechanical guarantees rather than prompt-level conventions.

The project was also inspired by a distinction between what a model is good at and what should not be delegated to a model. Gemini is useful for interpreting documents, recognizing patterns, proposing workflows and explaining decisions. It is not the right place to decide whether an actor currently has authority, whether two projects are separated by an ethical wall or whether a write was properly audited. Verletica therefore uses the model for interpretation and proposal while deterministic code owns governance.

Gemini proposes. The broker disposes.

This became the project’s architectural thesis. A model can suggest an intent, but the intent must pass through a single governed path before it can change the outside world.

What it does

Verletica is a self-serve governed AI fleet for small and midsize businesses. Onboarding creates an organization, a founder principal and a starter group of agent principals. The starter pack is not just a set of prompts. It installs named agents with distinct kinds, charters, scopes and organizational roles. The code treats those agents as principals in a directory rather than as anonymous chatbot sessions. 2

All of this is reachable through a full Next.js web application, not only through the API. A guided onboarding form creates the organization and installs the starter fleet; the workspace surfaces projects, staffing, commitments, barriers and the hash-chained audit trail; and a unified Needs-you queue collects every moment that requires a human decision — held financial intents, process offers, drift findings and failed runs — with the evidence attached to each. Held intents have their own detail pages showing why the broker stopped an action and what would need to be true to release it.

The user can add departments or projects, staff agents to particular projects, define information barriers and create commitments such as spending limits or delivery obligations. Those objects are persisted in typed contracts and repositories. Authority does not live as a permanent permission field on a principal. It is resolved from current staffing at the time of the request, which means a staffing change can change what an agent is allowed to do without rewriting the agent’s identity.

An agent run follows a deliberately narrow sequence. The runtime first resolves the principal, verifies that it is an active agent, loads its charter and checks any registry pin. It computes an effective budget by taking the tighter limit between the agent definition and the charter ceiling. It then creates a durable WorkflowRun with nodes for context, reasoning and action. Each node is updated as it moves through the run so an interrupted workflow leaves a record of where it stopped. 4

The agent gathers context through MemoryBank as itself. It does not read a raw storage adapter. The memory facade retrieves candidate material, applies the emission gate for the asking principal and records what was released, redacted or withheld. The model receives the resulting context, then returns a strict JSON response containing a summary and proposed actions. The parser rejects malformed JSON, unknown tools, invalid costs, malformed project lists and actions not present in the request header’s published tool snapshot. A plausible-looking action is never silently repaired into something executable. 4

Each accepted proposed action becomes an Intent. The broker evaluates that intent through one ordered path. The order is part of the design rather than an implementation detail.

Stage	Implementation question
Identity and charter	Is the principal active, published and acting within its charter?
Staffing	Does current staffing give this principal authority in the target project?
Scope and barriers	What projects can the action actually reach, including projects implied by referenced records? Does it cross a hard separation?
Commitments	Does it violate a confirmed and currently active business commitment?
Collisions	Does it conflict with another in-flight intent for the same operation or resource?
Approval	Does it require a human decision, especially because it touches money or another consequential resource?
Audit and dispatch	Has the decision been recorded before the connector write is allowed to occur?

The broker is designed to be total. It always produces a decision. An unexpected exception becomes a recorded rejection instead of escaping as an error with no decision attached. The audit entry is appended in a finally block, including rejection and failure paths. In enforced mode, post-decision invariant checks run before connector dispatch. If those checks detect a broken governance foundation, the broker refuses to send the pending external write and poisons the broker instance against further unsafe execution. 6

The memory system is similarly centralized. MemoryBank is the only public path to the semantic, relational, procedural and causal stores. Its ingestion path screens inbound text, refuses instruction-like content, removes identifying detail when needed, records redactions and stores an embedding for semantic material. Its emission path takes a required asker_principal_id and can release content whole, release a redacted view or withhold it entirely. The redacted view is computed for the current reader and is never written back onto the shared node as though it were the canonical record. 5

This applies to more than vector search. Similarity queries, causal derivation walks, relational neighbor reads and workflow retrieval all pass through the same access discipline. Even an empty or failed read is logged. The result is a memory model that can answer not only “What do we know?” but also “Why do we know it, who was allowed to see it and what was withheld?”

Verletica also has an explicit time dimension. The heartbeat is a deterministic between-task maintenance pass. It checks for active commitments past their expiry, pending confirmations older than seven days, findings from different principals that cite the same commitment and intents still waiting on a human. It records a durable HeartbeatRun, but it does not directly mutate the organization. A finding or hold must still be proposed through the Diagnostic agent and filed as a brokered intent. 7

The learning pass uses a seven-day window of structured work events plus prior candidate or promoted experiences. The model is asked to notice recurring patterns, but the surrounding code constrains what counts as a trustworthy lesson. A response is limited to five insights, must cite known event ids, cannot cite the same event twice and needs at least two distinct episodes for a general lesson. It is also rejected if it tries to grant access, change policy or assume approval authority. 8

The end-to-end proof test demonstrates the intended product loop rather than testing isolated utilities. It onboards an organization, installs a starter fleet, creates departments, adds a wall, staffs one planner per side, processes three differently worded versions of the same work sequence, merges them into one process offer, confirms the offer into a playbook, flags later drift, resolves the finding and rejects a second resolution as a conflict. It then ingests confidential West-side memory and verifies that the West planner can retrieve it while the East planner cannot. 9

How we built it

The implementation is organized around boundaries. The main Python backend uses FastAPI for the API layer, typed Pydantic contracts for domain records and repository interfaces for storage. A local file-backed document store supports reproducible development and demos. Cloud adapters provide the corresponding production path through Firestore. The goal is that changing storage does not change the governance model.

The agent layer is separated from connectors and storage. agents/runtime.py imports the Broker and MemoryBank abstractions but does not directly import a storage adapter, credential or model client. That restriction is reinforced by boundary checks. A future contributor therefore cannot casually add a shortcut such as reading a raw collection inside an agent and bypassing the memory gate.

The model seam is also explicit. ModelProvider owns generation and tracing. Reasoning runs on gemini-3.7-flash, and semantic memory retrieval uses the gemini-embedding-001 embedding model. The runtime constructs prompts from the agent definition and organization-authored skills, calls the provider once for the reasoning step, parses the response and files intents. The model never receives a connector with unrestricted write authority. It receives a snapshot of allowed tools and its output must validate against that snapshot before the broker sees it.

The governance contracts make the policy objects concrete. A Commitment carries provenance, review state, temporal validity and constraint information. Extracted commitments remain evidence until a human confirms them. A Barrier contains disjoint project groups and is hard-deny by construction. An Intent carries the proposed target, action, payload, justification and declared project reach. The broker reconciles that declared reach with referenced records so an under-declared action is still checked against the projects it can actually touch. An AuditEntry contains the decision, rule, identity, previous hash and computed entry hash. 10

The broker’s write boundary is connector-based. Connectors are registered by target system and action, and dispatch is only available from an active broker context. This makes an external write structurally different from an ordinary database mutation. The write is the final step after the decision and audit record, not an incidental side effect from a model tool call.

The memory implementation uses four internal stores. Semantic memory supports retrieval and embeddings. Relational memory represents links between nodes. Procedural memory stores workflow definitions. Causal memory stores derivation links that allow an answer or decision to be traced back through prior events and source spans. The public facade prevents callers from selecting an ungated route into any one of these stores.

The system has two kinds of observability. Turn and model activity is represented as nested spans with identity, charter, memory, model and tool information. Governance activity is represented by the audit chain. Trace export is allowlisted so private prompts, documents and message bodies do not leave the process simply because a tracing integration is enabled. The audit chain is verified when the broker starts and each new entry points to the prior entry hash.

The repository also treats evaluation as part of the architecture. The invariant suite checks properties such as “external writes are audited,” “memory reads are gated,” “authority comes from staffing” and “audit history remains reconstructable.” The whole-loop test is important because it verifies the composed behavior across onboarding, fleet installation, process learning, review, memory isolation and conflict handling rather than proving only that individual functions work.

The demo script provides a second form of reproducibility. It uses a temporary local store, deterministic identifiers and fixed model responses, so the governed loop can run without a cloud account, live model call or web server. The script provisions a diligence scenario, invokes agents through transport, runs a heartbeat, extracts and confirms a commitment, holds an action above a price cap, runs a work graph and prints the hash-chained audit trail. A capture-replay provider is used for the workflow-authoring portion, while the same provider seam can be connected to a live Vertex-backed model in deployment. 12

Challenges we ran into

The first challenge was recognizing that authorization is not a static property of an agent. A principal can be staffed on one project today and removed tomorrow. If authority is placed inside a prompt or copied into a long-lived message, it becomes stale. Verletica resolves staffing at the moment of action and keeps principal identity separate from current authority. This required the runtime, memory gate and broker to agree on the same answer to “who is this actor allowed to be right now?”

The second challenge was making it difficult to bypass governance by accident. A conventional codebase can have a policy helper while still allowing a lower-level module to write directly to storage or a connector. Verletica addresses this with narrow seams, active broker context checks, import-boundary tests and a single dispatch path. The broker also records a decision on unexpected failure because an exception without a decision is a dangerous intermediate state.

The third challenge was that information walls have to work in both directions. It is not enough to hide a confidential node when it is written. A permitted-looking query can still leak it later through semantic search, a causal explanation, a relational neighbor or a workflow definition. That is why the memory facade requires the asker on every read path and why release is evaluated at emission time. The system distinguishes whole release, redacted release and withheld content rather than treating visibility as a simple boolean.

The fourth challenge was reconciling model flexibility with machine-checkable behavior. Agents need to express plans in natural language and recognize that differently worded episodes may describe the same process. At the same time, arbitrary model output cannot be treated as an action. The runtime therefore uses strict JSON parsing and tool-scope validation. The learning pass adds citation requirements and rejects language that attempts to change policy or grant authority. This pattern allows the model to be creative about interpretation while keeping its authority narrow.

The fifth challenge was handling collisions that are invisible to individual agents. A local permission check can approve two separate actions even when their combined effect violates one commitment. Verletica computes stable operation keys and examines in-flight intents, including resource specificity where it is available. Missing specificity is treated conservatively rather than assumed to mean that two actions are unrelated. The result is a hold with assembled evidence rather than a silent race.

The sixth challenge was designing learning that does not quietly become policy mutation. The heartbeat detects staleness and composition candidates but does not write the resulting change. The model-backed learning pass can describe a repeated pattern, but it cannot grant access, change rules or decide policy. A human confirmation is required before a proposed process becomes a named playbook. Later reviews can flag drift, but resolving the finding is also an explicit, conflict-aware action.

A practical challenge was reproducibility. Live model calls and cloud services are useful for production but make debugging and judging harder. The repository therefore includes local storage, fixed providers, capture-replay fixtures, deterministic ids and a demo path that can run without credentials. This makes it possible to inspect the governance loop independently from model availability.

Accomplishments that we're proud of

The accomplishment we are most proud of is that governance is not presented as a policy document beside the agent system. It is implemented as the path an action must take. The broker checks the intent, records the decision, runs invariant checks and only then dispatches the connector write. That makes “every write is audited” a structural property supported by tests rather than a convention described in a README. 6

We are also proud of the distinction between model-backed work and deterministic control. The model can extract an obligation from a document, recognize a repeated workflow or propose a topology. It cannot make an unconfirmed commitment enforceable, bypass an information barrier, grant itself access or turn a learning insight directly into policy. This division gives the system a useful answer to a difficult question: Where exactly is the model allowed to be uncertain?

The composite memory bank is another important accomplishment. It treats organizational memory as more than a vector database. Semantic facts, relationships, processes and causal history have different retrieval behaviors, yet they share one access boundary. The causal path is especially valuable because it lets the system connect a current answer to the events and source spans that explain why the organization reached that state.

The whole-loop starter proof captures a meaningful product behavior. Three differently worded histories become one process offer instead of multiple duplicate suggestions. A human confirms it into a playbook. A later review detects consistently missed outcomes. A resolution is stored with a reason, and a second resolution produces a conflict instead of overwriting history. The same test then checks that one department’s confidential memory does not cross to another department’s planner. 9

We are proud of the counterfactual design as well. A blocked action is not only a dead end. The system can replay the same history without enforcement and show the road not taken. This turns a guardrail into something inspectable: the owner can compare the action that was held with the consequence the harness prevented.

Finally, the project demonstrates that an agent fleet can be autonomous without being silent or unbounded. Agents continue work asynchronously, maintain durable run state, perform heartbeat checks and raise a single actionable item when they cannot proceed. The system does not confuse autonomy with permission to improvise past a boundary.

What we learned

We learned that the most important component in an agent system may be the one that never calls a model. The heartbeat is intentionally deterministic because expiry, pending age, held-intent counts and cross-principal composition are better treated as mechanical checks. The model can help interpret the findings later, but it should not be the reason a basic maintenance check did or did not run.

We learned that memory security has to be enforced on emission as well as ingestion. Scrubbing a document before storage is necessary but not sufficient. A node may be safe in the shared store while a derived answer, relational edge or causal explanation still reveals more than the current asker should know. The same identity-aware gate therefore has to sit in front of every path that returns content.

We learned that a human approval queue is more useful when it is a unified decision surface. Holds, process offers, drift findings, failed runs and agent replies all represent moments where the organization needs to decide or understand something. Putting them into one Needs-you surface turns interruption into a manageable operating rhythm rather than a collection of disconnected alerts.

We learned that citations are not only for external research. They are a control mechanism for organizational learning. Requiring a general lesson to cite multiple known episodes discourages the model from elevating a one-off event into a permanent process. Requiring source spans for evidence also makes explanations more honest when a reader can see only a redacted version of the underlying node.

We learned that safe autonomy needs an explicit failure philosophy. A bounded retry budget, a durable run record, a clear refusal and one actionable escalation are better than endless retries or a vague “agent failed” status. The user should know whether the system was blocked by authority, a barrier, a commitment, a collision, validation or infrastructure.

The broadest lesson is that agent governance is not one feature. It is a composition of identity, memory, workflow state, policy, observability and human decision points. Weakness in any one of those layers can make the whole system appear autonomous while leaving the organization unable to explain what happened.

What's next for Verletica

The next step is to make the existing architecture easier to use and easier to verify in real deployments. The core already has local and cloud storage seams, a registry, brokered writes, asynchronous runs and an evaluation suite. The product work now is to turn those capabilities into a guided path that lets a small business move from onboarding to a trustworthy first workflow quickly.

Next area	Direction
Production integrations	Expand the connector catalog while keeping every integration behind the same brokered write boundary and audit contract.
Fleet lifecycle	Add richer registry version management, staged rollout, deprecation and rollback behavior for agent charters and workflow definitions.
Human decision experience	Improve the Needs-you queue with clearer evidence, approvals, amendments, conflict explanations and counterfactual comparisons.
Learning quality	Add more evaluation fixtures for recurring-process detection, abstention, citation quality and policy-overstep resistance.
Operational memory	Improve causal projections and provenance views so users can move from a decision to its origin without exposing restricted material.
Deployment hardening	Complete live-cloud verification across Cloud Run, Firestore, Vertex-backed model calls, screening and telemetry, then document the operational runbook.
Measurement	Track useful autonomy metrics such as work completed without micromanagement, decisions escalated, blocked violations, time to resolution and repeated-process precision.

We also want to make the architecture more accessible to teams that do not have a dedicated agent operations group. That means better onboarding language, safer defaults, connector setup that explains its consequences and a visual explanation of why an action was allowed or stopped.

Longer term, Verletica can become a portable governance substrate for agent fleets across different industries. The domain-specific layer should describe the organization’s work while the core continues to enforce identity, scope, barriers, commitments, collisions, audit and memory gates. The strongest version of the product is not an AI employee for one narrow workflow. It is a reusable way for organizations to adopt many agents without losing the ability to reason about authority and consequence.

The vision is simple: businesses should be able to delegate more work to AI without delegating away accountability. Verletica is the system we are building to make that possible.

References

Built With

• docker
• fastapi
• firebase-authentication
• gemini
• google-adk
• google-cloud
• google-cloud-firestore
• google-cloud-logging
• google-cloud-model-armor
• google-cloud-run
• google-cloud-secret-manager
• google-cloud-tasks
• google-cloud-trace
• google-genai-sdk
• google-vertex-ai
• next.js
• node.js
• opentelemetry
• python
• react
• react-flow
• recharts
• tailwind-css
• tanstack-react-query
• typescript