What Should Stay Inside Your Company After an AI Development Project?
Netsujo Inc. ·
After you introduce AI into one business process, does introducing it into the next become easier?
If each project means explaining the requirements from scratch, rebuilding quality criteria and finding someone to ask about operations, you may simply accumulate more systems. Individual development projects can be complete while your company’s ability to make decisions remains much the same.
In its implementation support, Netsujo focuses on leaving customers with something they can use for their next decision, alongside the implementation needed today. We make the reasons for decisions, methods for checking quality and operating procedures transferable to the next person.
Preserve the Reasons Behind the Design
Consider a system that answers questions by referring to internal documents. The finished interface and source code may not explain which documents it can consult, which questions were excluded or why a human review step was retained.
With those reasons available, the next person can decide what to revisit before extending the system to another department. They can also more readily avoid carrying old settings forward after the underlying assumptions have changed.
Keep the documentation detailed enough to support decisions. Alongside “this is how it was configured,” it helps to record the business purpose, constraints considered, alternatives not chosen and conditions that would prompt a review. For a small implementation, a single decision record may be enough.
Hand Over Something the Next Person Can Check
When responsibility for operations changes hands, an explanation of what worked may not be sufficient.
Which inputs were used to assess quality? Which errors must not be missed? When information is insufficient, how should the AI behave, and what should it pass to a person? Keeping examples like these lets the next person compare quality before and after changing settings or models.
Depending on the project, the handover can cover:
- Design decisions, the information the system may reference and the scope of its authority.
- Example evaluation inputs, expected behavior and how failures are handled.
- Who maintains the system, how to stop and recover it, and when to seek external support.
Ownership of deliverables, permitted uses, maintenance responsibilities and update costs need to be checked against the contract and the products and licenses used. Every component need not be custom-built. Existing products and public technologies can be used while retaining the records that the company needs for its own operations.
Separate Reusable Methods from Customer-Specific Information
A configuration used in one project will not necessarily work immediately in another. Even similar business processes can differ in accessible information, the consequences of errors, responsible decision-makers and existing systems. Before reuse, check how far the earlier assumptions still apply.
Customer data, conversations, business know-how and source code cannot simply be assumed available for another project or your own product. Check the contract, rights, purpose of use and agreement with the customer, rather than deciding solely on whether information has been anonymized.
Where the rights and conditions permit it, standardizing evaluation procedures, ways to define requests or mechanisms for checking authority can narrow what must be reconsidered in the next implementation. Customers also benefit from being able to see what carries forward and what needs to be checked again.
| Part of the diagram | Meaning |
|---|---|
| What goes back to the customer | Agreed deliverables, decision records, evaluation examples, and procedures for updates, stopping and recovery |
| Before reuse | Check the contract, rights, purpose of use and agreement; only the permitted scope becomes eligible for reuse |
| What needs to be checked | Customer data, conversations, business know-how, source code, procedures and shared components |
Anonymization alone does not determine permission to reuse something. The permitted scope is checked for each project.
Netsujo’s Public Technology and Services
Alongside individual support, Netsujo provides the open-source Agent Role Contracts project and its own service, Netsujo SIGNAL. Both address decisions and checks involved in getting work done, but they operate in different areas.
Agent Role Contracts checks for inconsistencies in declarations of AI agent roles, work scope, reviewers and related responsibilities. Actual operating permissions are managed in the execution environment, and the quality of deliverables is checked separately. The public implementation can be tried locally to assess where it applies.
Netsujo SIGNAL is a continuous improvement service that develops a company’s website into a sales foundation: a place where customers can discover the company, understand and compare its offering, and move toward purchasing or placing an order themselves. Within the authorized scope, it traces causes as far as the code and turns findings into improvement specifications that the customer’s AI, developers or existing development company can act on. It aims to accumulate explanations and decision support on the website so that people can spend their time on work requiring individual conversations.
The existence of these products alone does not establish the results or benefits of an individual implementation. In each engagement, evidence from that project is needed to establish what was implemented, who used it and what changed.
A Record of Detecting and Repairing an Inconsistency with ARC
ARC publishes a sample that reproduces a configuration inconsistency using an experimental adapter for CrewAI. CrewAI is a development framework for assigning roles to multiple AI agents.
The sample compares the permitted modification scope for a role with the output destination specified by a task. It changes the output destination in one place, checks that the declaration fails validation, and then restores the original value.
| Specified output destination | Validation result |
|---|---|
docs/example.md | PASS |
Changed to secrets/production.txt | FAIL |
Restored to docs/example.md | PASS |
The diagnostic code for the out-of-scope declaration is TASK_WRITE_SCOPE_OUTSIDE_AUTHORITY.
The independent reproduction record for PR #51, merged on October 6, 2026, confirms that the same code candidate was checked on a second machine. The initial pass, failed validation and pass after repair were reproduced there. All nine focused tests also passed.
What was checked was consistency between the supplied declarations. CrewAI was not executed, and no files were written. The adapter is experimental; execution-environment permissions and the quality of deliverables still require separate checks. The exact scope is available in the public code and verification instructions.
What this example leaves behind is both an explanation of the rules and a mechanism for detecting inconsistencies and checking them again after repair. In individual engagements, we similarly focus on leaving customers with something they can use for later decisions and verification, within the applicable contract and rights.
Turn an Explanation of a Pass into a Reproducible Check
This verification preserves the input that passed, the change that produced a diagnostic and the result after repair in a form another person can check.
A small experiment that changes only the output destination keeps the verification focused. When several settings change at once, it becomes harder to identify why a diagnostic appeared. Here, the change is limited to checking the mismatch between the permitted scope and the specified scope.
Checking the same code candidate on a second machine also matters. A result that succeeds only on its author’s machine may depend on local settings or unsaved changes. Fixing the code candidate and checking whether the same procedure produces the same results makes the scope of the handover more concrete. The published record reproduces an experiment against that fixed candidate. Results in another environment or after changes need to be checked again.
The same principle helps with customer handovers. Alongside examples that should work, leave examples that should be stopped or referred to a person. For a system that consults internal documents, distinguish questions with supporting evidence, questions with insufficient information and requests for information outside the permitted reference scope. With expected responses and conditions for human handoff preserved, the next person can compare behavior before and after a change.
Make Clear What a Pass Establishes
Consistency of declarations checked by ARC, operations permitted by the execution environment and the quality of a generated answer are different things to verify. Consistent declarations still leave execution-environment settings and answer correctness to be checked by other methods.
If that boundary is unclear, someone seeing a passing validation result may assume that actual operations are safe as well. Verification records therefore need to state what was not executed, alongside the inputs and results. In this sample, neither CrewAI execution nor writing a file to the output destination took place.
In records handed to customers, place “verified” next to “what to check next.” If a connection works, the next question is whether information can be handled within the permitted scope. If answers work for the selected examples, the next question is whether normal business exceptions can be handled. Use a pass as information for the next verification step, rather than interpreting it more broadly than the evidence supports.
Four Concrete Things to Leave at Handover
For a system that answers questions using internal documents, the handover can be made concrete as follows. This is an illustrative structure for agreeing the deliverables needed in each project.
| What to leave | Example contents | What the next person can decide |
|---|---|---|
| Decision records | Target department, permitted reference sources, excluded information and the reasons | What to revisit before extending the system to another department |
| Evaluation examples | Inputs, expected behavior and errors that must not be missed | How quality differs before and after a configuration change |
| Operating procedures | Update owner, checking methods, and the sequence for stopping and recovery | How to respond when information is outdated or the system stops |
| Change history | Change date, affected version, reason and re-verification results | What changed, when it changed and how far it can be rolled back |
Adjust the amount of documentation by checking whether a person can process a case and find the decisions needed when an exception occurs. Short records accessible from the actual work can be more useful than adding detailed explanations that go unused.
Start Product Learning with the Value Returned to the Customer
For Netsujo, developing learning from individual engagements into public technology and its own services is a way to keep improving the quality of its support. Collecting customer information is not an end in itself. The first responsibility is to return the agreed deliverables and records the customer can use in operations.
ARC makes inconsistencies between role and task declarations testable. SIGNAL connects website improvements to implementable specifications, so that customers can resolve questions and move toward comparison and selection. The immediate subjects differ, but both share the aim of leaving the next person able to decide and act.
For example, if SIGNAL identifies that a website makes product eligibility or implementation steps difficult to understand, the work goes beyond reporting traffic. It establishes which page should explain what, who will implement the change and what will be checked afterward. This is an example of the service’s value. Evidence of an effect on sales would require separate measurement for the customer concerned.
If the customer’s existing development company or AI can act on the improvement specification, that delivery setup can be used. Being able to follow the reasoning and verification method even after the responsible person changes provides a starting point for the next improvement.
Help the Customer Choose Its Next Step
Netsujo’s AI implementation support involves understanding the customer’s business and working environment, then moving from problem definition to implementation and operational design with the necessary specialists. We clarify what the customer decides, what Netsujo handles and what is passed to the existing development company, and agree the required deliverables and handover scope.
Previous decision records and evaluation examples should be useful when discussing the next implementation. Even when responsibility changes hands, people should be able to decide whether to continue operations or revisit them. We design for that capability alongside the working system.
Before commissioning development, tell us who inside your company should be able to make which decisions once the work is complete. We can define the support scope together, starting with what needs to remain in your organization.
Explore AI implementation support / Discuss the capabilities and records to retain after implementation