What is an AI software factory? Company context, software and agents with Teriyaki

An AI software factory starts with real work, connects to company systems and turns context into software and AI agents that teams can check, use and improve.

A team spots repetitive work. Someone builds a promising demo. Then come the questions that decide whether software or an agent will ever be used: which systems can it access, which company rules apply, what happens with exceptions, who checks its actions, and who maintains it after release? A software factory exists to answer those questions as part of delivery.

What ‘factory’ means in software

It is a repeatable system that turns a real need into a checked release: a tool, an application or an AI agent. Its inputs are a task, examples, company context and constraints. Its outputs are something people can use, tests, a trace of decisions and a way to improve the next version. AI can accelerate several steps, but a coding agent alone is not the factory.

A tool can perform a bounded operation; an agent can follow a multi-step workflow, consult context and ask for approval when an action crosses a boundary. Both need evidence that they behave as intended. The important unit is the verified change people can actually use, not the amount of code generated.

Why faster code is not enough

Once generation becomes fast, the bottleneck moves to choosing the right work, giving the system trustworthy context, verifying outputs and adopting them in production. A useful factory therefore has to coordinate the entire delivery path, rather than simply run a coding agent. The results still depend on the task, the team and the controls around it.

• Context: documents, rules, permissions and real examples must be available and current.
• Specification: a person confirms the intended behavior and the cases that matter.
• Verification: tests and review need independence from whoever produced the change.
• Operation: releases need ownership, logs, costs, feedback and a path to correction.

Enterprise connectors: bringing the real work into view

Work rarely lives in one application. A purchase order may be in the ERP, the invoice in a document archive, an exception in email and the approval rule in a procedure. Enterprise connectors are controlled bridges between the factory and the systems that hold these pieces. They let software and agents use the information a specific task needs, and, where authorized, return a result to the right system.

Teriyaki connects to authorized company systems through enterprise connectors. Each integration needs a clear scope: which data it reads, which actions it can perform, whose permissions it follows and what gets logged. A connector does not grant an agent the right to see everything or change a record without approval. The boundary should be designed with the team that owns the process.

The company brain, in plain language

Think of a shared working memory for the company. It brings together what a team needs to understand a task: relevant documents, process steps, people responsible, decisions already made and the exceptions learned over time. It also records where each piece of information came from and who may use it. This is what we mean by a company brain: organized, up-to-date context that software and agents can consult with permission.

Suppose an agent must decide whether an invoice needs review. The invoice alone is not enough. It also needs the purchase order, the supplier’s history, the current tolerance rule and any prior exception. The connectors bring those pieces from the authorized systems; the company brain helps connect them to the right process and source. If a piece is missing or contradictory, the agent should flag the gap for a person instead of inventing an answer.

Teriyaki: from a task to software or an agent

Teriyaki is Hoplo’s AI software factory. The starting point is deliberately ordinary: someone describes a repetitive task in natural language and attaches real examples. The factory asks for missing details, identifies the company systems and context the task needs, proposes a specification and test cases, and waits for confirmation before building software or an agent.

A coding agent then builds the software or agent. A separate validator checks it, including on cases hidden from the builder. A person approves the Factory release. The resulting capability can be used as a form, API, chat tool or through MCP, depending on its scope. The downloadable release includes source code, tests and the specification; runs and costs are recorded. Duration and outcome depend on the task and its requirements.

Where human judgment remains essential

A validator can catch failures against explicit requirements. It cannot decide on its own whether a requirement represents the right business policy, whether a dataset may be used, or whether an agent’s action has consequences the team accepts. Those decisions need an owner. The owner should confirm the specification, decide which actions require approval and be able to pause the workflow when reality differs from the test cases.

This boundary also makes the factory more useful over time. When a person corrects an exception, the correction can become a new test and a clearer rule for later releases. When a model or a data source changes, those tests give the team a way to check for regressions before replacing the working version. Reuse is valuable only if it preserves what has already been learned.

A practical example: checking incoming invoices

Imagine an accounts payable team that compares incoming invoices with purchase orders. A connector reads the order from the authorized ERP; another brings in the invoice. The company brain supplies the current tolerance rule and known exceptions. Software can extract and match the straightforward fields; an agent can follow the uncertain cases, explain the mismatch and ask a person to decide. It should never silently approve an exception the team has not defined.

The examples become test cases; the exceptions shape the specification and enrich the shared context; the reviewer sets the release boundary. After use, corrections and new cases improve the next version. This is an illustrative workflow, not a claim about a deployed customer installation or a measured return.

How to start without creating another isolated pilot

• Choose one frequent task with a clear owner, a known current process and access to representative examples.
• Map the systems, connectors and permissions needed; identify the rules the company brain can provide and the context still missing.
• Write down what ‘correct’ means, including exceptions, forbidden actions and who approves the result.
• Release a narrow piece of software or an agent, keep the code and tests, and observe where people intervene.
• Measure the whole workflow: time to usable release, corrections, adoption and cost per run. Compare with the previous process.

What to measure after release

A fast demo is an incomplete measurement. Record the baseline first: how long the task takes today, how many cases need correction, and where people wait for a handoff. Then observe the same workflow with the software or agent in use. Time saved on one step matters only if the whole task finishes sooner without moving extra work to another person.

Track false positives and missed exceptions alongside usage, cost per run, release lead time and the effort needed to update the system. Review these measures with the team that owns the process. If the result is rarely used, the reason may be access, trust, a missing exception or a workflow that was never a good candidate. The factory should make it possible to learn that quickly and change course.

The first result should make the next task easier: reusable software or an agent, tests that protect later changes, and a clearer, permissioned understanding of the company’s work. That is the compounding effect a software factory is meant to create. Teriyaki gives this approach a product and a delivery path; the team still owns the choice of work and the final decision to release.