When not to use OutSystems for AI, and what to do instead

First, recognize where it is a good fit

Consider a support team that already works in an OutSystems application. An assistant drafts a response, a reviewer checks the sources, and an existing operation sends the approved message. Keeping that experience in the application can avoid a second login, a second queue, and another copy of the business rules.

OutSystems Developer Cloud (ODC) documents connections to external model providers and custom model connections. Using an external model does not, by itself, require building a separate AI backend. Start by checking the available integration against the actual task.

This guide is about architecture choices, not a claim that OutSystems lacks AI features. ODC and OutSystems 11 (O11) are different offerings. Verify capabilities, limits, availability, and licensing for the version and environment you will actually use.

1. When the AI idea is still an experiment

If the open question is whether a model can extract the right fields from your documents, a complete business application is not the first thing to build. Start with a small test harness: representative files, expected fields, and a way to compare results. Use synthetic or approved data, not an unreviewed export from production.

A script or notebook may suit a team testing parsing libraries and model behavior. A native OutSystems prototype may suit a team already equipped to build there. Choose the shortest responsible path to the evidence, then decide what deserves a user interface. A successful demo is not yet a production design.

Better first step: test the difficult AI task before committing to the application around it. Keep the evaluation cases so they can become regression checks.

2. When the AI work needs its own runtime

Suppose your team needs a particular Python document library, a GPU-backed inference server, or an independently deployed retrieval pipeline. That is a reason to evaluate a dedicated service, not to force all of its dependencies into the workflow application.

OutSystems can remain the place where users submit work and review results. The external service can own the specialized processing. Define the request and response, who may call it, how versions change, and who gets alerted when it fails.

Do not add this split just because an AI diagram usually includes another service. If a supported native integration already meets the need and can be tested and maintained by the team, it may be the simpler choice.

3. When the work should not run inside one request

A large document may need text extraction, several model calls, and validation. Keeping a browser waiting for the whole sequence makes recovery harder when a connection drops. Design a job that can continue without the original page remaining open.

For a concrete constraint, the ODC system requirements list a 60-second execution timeout for an exposed REST API method. That is a limit on that method, not a claim that every OutSystems operation has the same limit. Check the limits of each step in your chosen implementation.

A useful alternative is to accept the work, return a job identifier, and show pending, completed, or failed status. A supported platform background mechanism may be sufficient; an external queue and worker may fit a specialized workload better. In either case, define retry limits, cancellation behavior, and how duplicate submissions are handled.

A worked example: reviewing a supplier document

Imagine a team already using OutSystems for supplier requests. It wants AI to suggest fields from uploaded documents, but its chosen extraction library runs in a separate Python environment. The first scope is a draft for review, not automatic supplier approval.

The proposed split below keeps request ownership and approval in the business application. An authenticated worker receives access only to the document for its assigned job. It returns proposed fields and source references, not a command to approve the supplier.

4. When several products need the same AI behavior

If a website, an OutSystems application, and a mobile product all need the same extraction logic, copying prompts and validation into each one creates several places to fix the same problem. A shared service with a versioned response can provide a common implementation.

The benefit is not automatic. Each caller still needs authorization, usage limits, and a way to handle an unavailable service. Shared behavior can also spread a bad change across every product. Keep a test set and a controlled rollout. If only one application needs the feature, a shared service may be unnecessary overhead.

5. When a simpler tool or a rule solves the problem

An internal team that needs occasional document summaries may be better served by an approved existing product than by a custom application. Check its data handling, access controls, and workflow fit before building a replacement. A custom review process or integration can change that decision.

Some tasks do not need a model. A total, a required-field check, or a fixed approval threshold belongs in ordinary, testable logic. AI can help interpret messy inputs or draft an explanation while the application calculates the amount and enforces the rule.

This is not a reason to avoid OutSystems. It can be a reason to build a smaller OutSystems feature without AI. Compare the actual recurring costs: platform scope, model calls, retries, storage, monitoring, review effort, and support. Do not assume a separate service is cheaper, or that an existing license makes every addition free.

6. When AI is being asked to replace permission checks

Do not use a model response as proof that someone may view a record, approve a request, or send a payment. This applies whether the model is called from OutSystems or from custom code. OWASP describes the risk of giving an AI system more tools, permissions, or autonomy than its task requires.

Keep access and state checks in the operation that performs the action. Let the model propose an output; let the application validate it and require review where appropriate. An external AI service does not make this boundary safe by itself.

Better design: an AI suggestion is an input to a decision, not permission to execute it.

7. When Agent Workbench execution costs change the equation

Do not budget for the model alone. Agent Workbench has an OutSystems agent-execution allowance to consider as well as the external AI provider bill. What a team calls an AI transaction is not necessarily the billing unit: the published OutSystems capacity policy uses Agent Executions, not tokens or completed business tasks.

As checked on September 21, 2026, that policy lists 10,000 Agent Executions per month and directs customers to their account team for additional capacity options and pricing. The public pricing page offers custom quotes, not a universal per-execution rate. Check your signed entitlement, any promotional terms, and renewal pricing before projecting the extra cost.

OutSystems also states that customers pay external AI providers directly for LLM token consumption. An included agent-execution allowance does not make those tokens free. Switching to a less expensive model can reduce the provider bill without changing your need for OutSystems execution capacity.

The architectural alternative is an ordinary server-side API integration or a dedicated AI service that does not invoke Agent Workbench. Our inference is that work performed entirely outside that runtime avoids consuming its agent-execution allowance; confirm how your specific integration is metered with OutSystems. Calling an external model from an Agent Workbench agent is not the same as running outside Workbench.

That distinction can matter for frequent, simple tasks that need little agent orchestration. But removing Workbench from the execution path does not remove your OutSystems application subscription, model charges, or operating costs. Agent Workbench may justify its capacity cost through integrated orchestration, monitoring, and governance. With a separate service, the team must provide and maintain the controls it needs.

Compare total cost per useful completed task, not just token price. Sources: the OutSystems capacity policy, pricing page, and external-model billing FAQ linked below. No customer-specific rate or guaranteed saving is assumed.

A simple volume check before choosing the runtime

Illustrative planning example, not an OutSystems metering rule: suppose a measured workflow averages three counted agent executions per request and handles 5,000 requests a month. That is 15,000 executions. If the applicable allowance is 10,000, the remaining 5,000 require a capacity discussion, not an invented price multiplied by a request count.

Confirm what counts before using that estimate: retries, agent handoffs, failed attempts, and development or test runs may affect the total. Ask how capacity is pooled and what happens at the limit. One user request, one model call, and one billable agent execution should not be treated as interchangeable.

For the same workload outside Workbench, estimate provider usage, infrastructure, engineering, and support. Include the cost of equivalent access controls, traces, evaluation, and recovery. Use the actual Workbench quote and both operating estimates to decide whether avoiding that execution-cost layer is worth the extra responsibility.

Choose the smallest architecture that passes the checks

Use this comparison to narrow the options, not to score a platform in the abstract. A failed requirement matters more than a long list of features you do not need.

• Check the exact model, data location, retention, and access requirements for the proposed service.
• Test slow responses, bad outputs, unavailable providers, and duplicate requests, not just the happy path.
• Name the owner of the workflow, the AI evaluation, and the production support path.
• Write down what would make you change the architecture, such as another consumer or a new processing requirement.

Questions that often come up

Do we need to move away from OutSystems to add AI? No. First evaluate the integrations available in your offering and the workflow you already have. A separate service is an option, not a prerequisite.

Is custom code always better for AI? No. It can offer control over libraries and runtime behavior, but the team must operate it. Control is only useful when it solves a real requirement.

What should stay outside the model? Authorization, exact calculations, and enforceable business rules. These may live in OutSystems or another trusted service. What matters is that generated text cannot bypass them.