Say your team runs a project tracking app with subscriptions, and asks a coding agent to add paid exports. By lunch the agent has the export button working in development. Before you send the change to customers, someone still needs to check what happens when the production API receives a payment and a customer tries to export a project.
An AI software factory needs a release process the team can repeat as agents finish more changes. Both people and agents need to know how to build and test a change, find the version in production, and see what happened if the release failed.
Start with one change and follow it into production. Make each step easy to repeat and give it a result that a person or an agent can check. You can then automate more of the work without losing track of what is happening.
Follow one feature across the app
For this example, the project tracker has a website, an API, a Postgres database, and customer sign-in. The paid export crosses several of those parts even though the customer sees one new button.
The agent can write the export code and make the button appear. The feature also needs to know who paid, which projects that person can read, and where the export file will go. Each of those decisions reaches another part of the app.
Suppose the payment provider sends the same event twice. If the handler creates a new entitlement each time, the customer may get access twice or receive two emails. Suppose the agent adds a database column but the migration never runs. The app can build successfully and then fail when someone clicks Export.
As agents produce more changes, the team needs to run these checks more often. Give the release process enough information to catch problems before customers do and to investigate the ones it misses.
Give every release a clear starting point
First, decide what code you are releasing. Keep the commit ID with the build and deployment record. A commit ID names one version of the source code, so everyone can check whether they are discussing the same change.
For the export feature, the team should be able to answer a simple question: does the running API include the payment handler and database change that were reviewed? “The latest version” is too vague when several agents are pushing changes.
Next, make the build repeatable. The process should read its settings from the repository and the deployment system, rather than depend on a developer's laptop. A new engineer or agent should be able to run the same build without asking which local files were used last time.
Keep secrets separate from source code and from public build output. If an agent needs to inspect a failure, it should be able to read the useful part of the log without receiving database passwords or customer records.
Test the customer action after the app starts
The build can pass and the API can answer its health check before you've learned whether a paying customer can use the export. Test that action with an account that has the right subscription.
In a test setup, sign in as a customer with an active subscription. Create a project, export it, and check the file. Then try the same action as a customer who has not paid. That customer should get the access behavior your product promises.
These checks are small enough to repeat after a release. They also give an agent a clear task. Instead of “verify production readiness,” the instruction can name the account, action, expected result, and evidence to save.
Keep test data separate from real customer data. If you run a small check in production, use an account and actions that are safe to repeat. A test that sends real invoices or creates customer-visible files needs a more careful plan.
Limit what the agent can change
The agent may need to read a failed deployment and propose a fix. That does not mean it needs permission to change every resource in the cloud account.
Separate the tasks. Reading selected logs, releasing an approved commit, and changing a database access policy have different consequences. Give each task the access it needs, and check that other actions are denied.
On AWS, a team can use temporary credentials and a narrowly scoped role. It can also keep the deployment credential in its existing release pipeline. The agent prepares a pull request, a person reviews it, and the pipeline performs the release. AWS IAM guidance
The important part is that the limit is enforced. A sentence in a prompt cannot stop a cloud API from accepting a request made with a powerful credential. See scoping Claude's production access for a fuller example.
Make a failure useful to the next attempt
Now suppose the export feature passes its tests, but a production request fails. The next agent session needs to know which release served that request, what the API returned, and what the app logged while handling it.
Start with the failed request rather than a broad instruction to “look at the logs.” Follow its request ID through the app output. The request ID is a label that lets you connect messages from the same call without copying the whole customer request into every tool.
With the matching logs, the agent can check whether the export handler ran, whether its database query succeeded, and whether the file upload failed. Ask for the result of each check before it changes code.
If the required log message is missing, add it as part of the fix. Leave out secrets and sensitive payloads. Better evidence makes the next incident easier for both agents and people.
Put the release process on Forte
On Forte, the API runs as a Service connected to a GitHub repository and branch. Forte handles the build and deployment workflow and keeps the result with the Service. When a release fails, the team can start from that deployment's stage and logs. Deployment guide
Once the Service handles traffic, its request records show status and timing. Include the X-Request-Id value in app logs to connect the messages to the right request. This gives the agent a path from a customer failure to the relevant app output. Websites use a separate hosting path and do not get these Service request diagnostics. Monitoring guide
Forte reduces the release and diagnostic setup your team has to maintain. Your team still owns the export code, tenant permissions, payment behavior, and database migrations. You still need to decide which changes an agent may approve and what happens when data must be recovered.
Try one complete release before automating more of the workflow. Pick a small change, follow its commit through deployment, test the customer action, and look into a deliberate failure in a safe environment. That exercise will show you where the next piece of automation can help.