Key takeaways
- Building yourself means choosing, connecting and operating compute, database, versioning, monitoring, access control and audit history, not just calling a model.
- Even with agent-specific cloud services, you would typically still pick, size, secure and connect the database, networking, permissions and alerting.
- The deciding question is who in your company will own that stack after launch, and what happens when that person leaves.
- A platform can take infrastructure assembly off your list, but not the business work of connecting systems and deciding which cases count as exceptions.
- Building on a cloud provider is the right call when you have your own developers who want to build and control every component.
What running an AI agent on AWS yourself involves
Running an AI agent in production on AWS means assembling several services and operating each of them after launch. The model call is often the smaller part: the rest is where the agent runs, where its data lives, how changes are tracked and who may do what.
AWS spells out the split in its shared responsibility model. A customer that deploys an Amazon EC2 instance manages the guest operating system, including updates and security patches, and configures the firewall on each instance. Customers also manage their own data and use IAM tools to apply permissions.
AWS also offers agent-specific services. Amazon Bedrock AgentCore describes a runtime with session isolation and built-in identity, and an observability view for tracing an agent's execution path and auditing its intermediate outputs. Even with these, you would typically still pick, size, secure and connect the rest: the database, networking, permissions and alerting.
This comparison uses AWS because its documentation was checked for it. For Google Cloud or Azure, check their own documentation for the compute, database and monitoring services you would assemble.
Worked example (illustrative): an agent that flags order exceptions from Monitor G5
| Dimension | Building on a cloud provider: what you source and own | Ronja: what the platform and runtime include |
|---|---|---|
| Compute | Choose where the agent runs, size it, and keep its operating system and dependencies patched. | Compute is part of the platform. Here, the runtime would execute the order check as a workflow started by a time trigger, such as every night, or by an event. |
| Hosting | Host the agent and any review screen, and configure network and firewall rules for each. | Hosting is part of the platform. A review screen for flagged orders would be an application your team opens, executed by the same runtime. |
| Managed Postgres and storage | Select, size, secure and back up a database for orders and flagged exceptions. | Orders and flagged exceptions would be kept in managed Postgres and data storage, in the same foundation as compute and hosting. |
| Connection to Monitor G5 | Build and maintain the integration, credentials and data mapping yourself. | Ronja has a Monitor ERP integration, and Presso runs Ronja on Monitor G5 data. Source permissions, data mapping and reconciliation are still necessary steps. |
| Versioning | Track changes to code, prompts and configuration, and keep a way to roll back. | Versioning is built into the runtime that executes both the order-check workflow and the review screen. |
| Monitoring | Set up tracing and alerts so a failed overnight run gets noticed. | Monitoring is built into the same runtime that executes the nightly run. |
| Access control | Define permissions for people and services, and review them as staff change. | Access control is built into the runtime that executes the workflow and the review screen. |
| Audit history | Decide what to log and how long to keep it, so you can show what the agent did. | Audit history is built into the runtime, so you can follow what happened in the run that flagged an order. |
Who would own and operate a self-built stack
In a company without developers, a self-built stack usually ends up with whoever set it up: the IT manager who runs the business systems, or an external consultant. The work does not stop at launch, because patches, permission changes, failed runs and model updates keep arriving.
That ongoing ownership is often the larger cost to weigh. Ask practical questions: who notices when the order data from the ERP changes shape, who approves a new user, who can explain last month's flagged orders, and what happens when that person moves on. If the honest answer is one name, the agent depends on one person.
Consultants can carry the build, but ownership then sits partly in a contract, so the agreement should say who operates, monitors and changes the agent after delivery, and how you take it over if you switch supplier.
On Ronja, access control, versioning, monitoring and audit history are part of the runtime, so your team does not assemble them. You still need someone who owns the process and approves the decisions that matter.
Control, ownership and data location across three paths
| Dimension | Build on a cloud provider | Consultants build and run it | Use Ronja |
|---|---|---|---|
| Infrastructure you assemble and operate | Every component, operated by your team or whoever you hire. | Whatever the consultant assembles, operated for as long as the agreement runs. | The runtime is part of the platform and includes access control, versioning, monitoring and audit history. |
| Approvals | Approval steps are typically something you design and build yourself. | Depends on what the consultant builds and the contract specifies. | AI interprets ambiguous input, deterministic code calculates and validates, and people approve consequential decisions. |
| Data location | On AWS, you determine where data is stored, including the geographic region. | Depends on the cloud and region the consultant picks. | Ronja's public security description states EU/EEA data processing as the default. |
| Transfers outside the EEA | AWS states customers can transfer data to countries without an adequacy decision, including the United States, in compliance with GDPR, so your setup decides it. | Check which services and subcontractors the consultant relies on. | Ask how the EU/EEA default applies to your setup. |
| Data rights | Check the provider's customer agreement, and plan how you will protect the data. | Defined in the consultant's agreement. | The customer retains all rights to its data; Ronja may process it only to deliver the service. |
| Certification | Plan how your own setup will be assessed, and check what the provider's certifications cover. | Depends on the consultant and the cloud chosen. | ISO 27001 certified; SOC 2 Type 2 is in progress and not complete. |
When a platform fits, and when building on a cloud provider is right
For
- Established companies with a stable core of ERP, CRM and finance systems and no development team
- IT managers and data or systems owners who must govern, secure and operate what gets built
- Business leads who want to remove manual work between systems, one process at a time
Not for
- Companies with their own development team that want to build everything on AWS, Google Cloud or Azure: building there is the right choice
- Teams that want fine-grained control over every infrastructure component and have the people to run it
- Companies that mainly need a new ERP or CRM, not software on top of the systems they have
What a platform does not replace
A platform can take infrastructure assembly off your list, but not the business work around it. Ronja is an agent-first cloud for non-technical companies: AI agents build, run and maintain your own software on top of the ERP, CRM and finance systems you already have.
Ronja is not a business system and builds on top of ERP and CRM rather than replacing them. It is not a BI tool either, since dashboards and reports are part of the platform rather than the product, and it is not an iPaaS: its integrations exist so that what is built can reach the data.
Connecting a system still takes effort on your side, and someone has to decide what counts as an order exception. If a rule like that needs a fixed, deterministic result, Ronja runs it as executable program logic rather than AI interpretation.
Starting narrow is a practical way to test which path fits. According to Marta Sjögren of Paebbl, the company's partnership with Ronja began with narrowly scoped use cases showing clear ROI and expanded from there.
If one bounded process like the order check is where you would start, the next step is to review it with Ronja.
Talk to us
Review one bounded process with Ronja.
Talk to usSources
Frequently asked questions
Who should own an AI agent stack in a company without developers?
Someone has to own patching, permissions, monitoring and changes after launch, not only the initial build. In practice that is often the IT manager or an external consultant. Before you build, name that owner, a second person who can step in, and how responsibility moves if a consultant is replaced. If you cannot name them, a platform whose runtime already includes access control, monitoring and audit history is usually the safer path.
Is Ronja SOC 2 certified?
Not yet. Ronja is ISO 27001 certified, and SOC 2 Type 2 certification is in progress but not complete. If your procurement process requires SOC 2, ask for the current status and plan your evaluation around it rather than assuming it will be finished by a set date.
Do we need AI expertise in-house to use a platform?
You need process knowledge more than AI expertise. The people who matter most are the ones who can say which orders count as exceptions, who should act on them and who grants access to the source systems. Technical ownership still matters, but on a platform it tends to shift from assembling infrastructure to governing what runs on it.