Oshoma Systems is an AI architecture company in Tacoma that runs governed multi-agent systems and builds its own products on that architecture. We also license the architecture to separate companies and advise organizations on how to govern the AI systems they build.
Request a working session.We build these systems with our clients, on infrastructure we operate. When something fails, it fails where we can see it, and the cost is ours.
An unbounded agent loop consumed several hundred dollars overnight; we traced its cause and introduced spend caps, a circuit breaker, and a monitor that alerts when a threshold is reached.
We paid for that lesson once, at our own expense. Like each failure that has changed how we build, it was recorded as a change to the rules our systems run under, and a client's system inherits those rules, not the failure.
The controls address one operational risk: continued execution that consumes money after an agent has stopped doing useful work. The approval rules built into our products address another: a decision the owner needs to retain as the work becomes automated.
Founded in Tacoma, Washington, in 2025, Oshoma Systems runs multi-agent systems in production across multiple Linux hosts and builds products on that architecture. One architecture, five fields: political consulting, legal services, food service, real estate, and salons. Working in English and Spanish, with Portuguese in demonstration.
Amaru Operative supports campaign messaging, narrative analysis, opposition simulation, debate preparation, fundraising copy, and field strategy, drawing on the founder's congressional and statewide field programs. It is in use by a Washington political consultancy through the 2026 campaign season and is built and operated by Oshoma Systems.
Tonantzin drafts social media posts from a prompt or photo for restaurants and small food businesses through the owner's messaging app. It publishes only after the owner approves and sends a daily reminder when nothing has gone out; it was deployed for a restaurant client in 2026.
Built and operated by Oshoma Systems.
Voz Inbound is an inbound AI receptionist for businesses taking calls in multiple languages, demonstrated for a real estate agency in Portuguese, Spanish, and English.
Built and operated by Oshoma Systems.
Voz Outbound is a WhatsApp messaging assistant built for the Tijuana market that answers messages and follows up with salon clients who have opted in.
Built and operated by Oshoma Systems.
Document and workflow tools supporting Washington criminal-record relief, used by licensed attorneys and nonprofit legal organizations. A multilingual assistant answers general questions and sends reminders. Clean Slate of Washington is a separate company and is not a law firm.
Clean Slate of Washington licenses technology from Oshoma Systems LLC.
Oshoma Systems builds and operates its own products; Clean Slate of Washington is a separate company using technology licensed from Oshoma.
Before an agent can publish or take another consequential action, the system checks whether that action requires approval from a designated person. Tonantzin's publication rule illustrates the mechanism: the owner reviews a draft before it can become a post on the account.
The memory layer stores approved decisions with the reasons behind them, then retrieves relevant entries when an agent handles related work. A reviewer can amend an entry when a decision changes, reducing the chance that later work relies on an outdated instruction.
Across the Linux hosts running production workloads, monitors track balance thresholds while spend caps and circuit breakers constrain continued execution. When a threshold is reached, an alert gives the operator a specific condition to investigate before deciding whether work should resume.
Carlos has worked on both sides of the regulatory table: inside state agencies and local government, and in a congressional office, where decisions about what an organization may do are made, challenged, and recorded. He founded Oshoma Systems in 2025 to build AI systems that keep those decisions where they belong, with a person who answers for them. He works in English and Spanish and lives in Tacoma, Washington.
We begin with a workflow the client needs to improve and examine where a person's judgment determines what happens next, including decisions that are currently handled informally. For Tonantzin, this means establishing approval responsibilities and how the owner handles days when nothing is ready to publish. The session produces a proposed scope and assigns unresolved questions to the people who can answer them before development.
We map the proposed workflow to agent roles and identify which actions require approval before the system can carry them out. The design specifies what the system may retain, sets spending limits, and names the person responsible for responding when those limits are reached or an approval remains unresolved. We record the agreed design so the client can check implementation decisions against it as development work proceeds.
We build the agreed workflow and test it with examples the client can judge, including cases where the agent should stop. In a publishing workflow like Tonantzin's, tests cover its approval requirement, including when the person responsible has not responded. We revise behavior that differs from the agreed design and run the affected tests again with the client.
Before deployment, we agree who will operate the system and how that person will respond to alerts or requests for approval. Spend caps and a circuit breaker address the kind of continued execution that caused our overnight loop incident; monitoring alerts the operator to threshold conditions. After launch, we review reported failures with the client and test proposed changes before applying them to the running system.
For organizations commissioning a governed system, a working session examines which automated decisions need human approval and what happens when a system exceeds its limits.
For venture partners with a market and a client need, the discussion starts with the product and whether Oshoma's architecture fits the work.
Oshoma's work requires a client who can define decision authority and participate in reviewing how the system behaves during development and operation.