The Modern AI Tech Stack: Models, APIs, Data, Cloud and Tools

An AI feature can look simple from the outside: a person provides an input, the product does useful work, and a result appears. Making that experience dependable requires much more than a model call. Behind it sit product logic and workflows, models and agents, APIs and data, payments and billing when the product charges customers, cloud and compute, security, and the tools used to build and operate the system. Specific products will change, but each job still needs a clear owner.

The best place to understand the stack is the part a person can see and control. The interface determines what information is requested, how the steps unfold, whether progress is visible, and how a result can be reviewed or corrected.

AI makes those product decisions more important, not less. People need to know what the system is doing, when it needs their input, where uncertainty remains, and how to recover when a result is wrong. A well-chosen stack should support that clarity all the way down.

Product logic decides what happens next. It validates inputs, applies permissions, chooses tools, handles state, and determines when a task is complete. Agentic behavior belongs inside this product logic, not outside it.

A deterministic step follows rules written in code, so the same valid input produces the same expected outcome. Field validation, calculations, permissions, limits, database updates, and irreversible actions should usually be deterministic. A model can help interpret an ambiguous input, but the product should still control what is allowed and what produces a final result.

Before adding AI to a step, ask whether a normal function, database query, or fixed rule can solve it clearly. Use a model where language, ambiguity, or judgment is part of the problem. Use ordinary code where the answer is already known. This keeps the system easier to test and avoids adding model cost and uncertainty to work that does not need them.

A Next.js Route Handler could receive a refund request, but the application's own code still needs to check the order, confirm the refund window, enforce the amount limit, and either apply a narrowly defined rule or route the final action to a person. The model can recognize the intent and draft a reply. Flexible interpretation and hard rules have different jobs.^[2][3]

Models provide capabilities such as generation, extraction, classification, reasoning, vision, and speech. They are useful when the product needs to work with unstructured information or produce an answer that cannot be reduced to a fixed rule.

Choose a model for the task rather than treating the largest model as the default. A smaller or faster model may be enough for classification or extraction, while a harder reasoning task may justify more capability. Test candidates with realistic inputs and judge the complete result, not the provider name alone.

Many text-model APIs meter usage in tokens, which are units of the content a model processes or generates. Input tokens can include instructions, user content, retrieved context, tool definitions, and tool results. Output tokens can include generated text, tool-call arguments, and reasoning. Cached input is previously processed prompt content that a provider can reuse when the same stable material appears in later requests, rather than processing it as entirely new input.^[13][14]

Providers often price new input, cached input, and output at different rates. A multi-step agent can create several model calls, retries, and separate tool charges, so estimate the total usage required for one completed task rather than the price of one request.^[13][14]

For the support tool, a model from OpenAI, Anthropic, or Google could draft a reply from the customer's message and relevant policy text. The useful comparison is whether each candidate produces an accurate, editable draft at an acceptable speed and cost with the kinds of requests the product actually receives.

Agents combine model decisions with tools, memory, and repeated steps. They are most useful when a task genuinely requires planning, tool selection, changing information, or multiple attempts. A stable workflow that can be completed with one well-structured model call or ordinary code does not need an agent.

OpenAI, Anthropic, and Google each support tool-use or function-calling patterns that can let a model request an order lookup. The surrounding application determines which actions are available and whether approval is required. The model cannot issue a refund or send the final message unless the system explicitly gives it a tool and permission to do so.^[3][15][16]

When a task spans several decisions, agent orchestration manages the sequence: give the model the current state, let it choose from allowed tools, execute the selected tool, return the result, and repeat until the task is complete, a limit is reached, or a person needs to review it. LangChain can run this model-and-tools loop in code, while n8n can connect a chat model and tools through an AI Agent node inside a workflow. These are useful options for branching, multi-step work, but they also add state, failure modes, and cost. A routine support reply may still need only one model call and ordinary application code.^[17][18]

APIs connect the product to outside capabilities. Databases hold accounts, product state, permissions, and durable records. Retrieval systems help locate relevant material. Temporary working memory carries context through a task.

Web access is one example of an outside capability. The Tavily Search API can return current web search results and source URLs for a query, while Firecrawl can turn a permitted web page into clean markdown or structured data for later processing. These tools bring external material into a workflow; they do not replace the product database, define what may be collected, or make retrieved content automatically trustworthy. The application still needs source checks, scope limits, retention rules, and respect for site terms and access restrictions.^[27][28]

Treat these as separate jobs. Product records need consistency and access controls. Search needs relevance. Agent memory needs boundaries and expiration. Putting every kind of information into one undifferentiated store makes behavior harder to inspect later.

In the support tool, Supabase Auth could sign staff in, while application tables in the same Supabase Postgres database store ticket history and approval records. An existing commerce API could supply order details, and PostgreSQL full-text search could find relevant policy text. The temporary context used to draft one reply can expire after that task. If durable records, search results, and working context are treated as the same kind of memory, an old conversation may influence a new request in ways nobody intended.^[4][5]

A product that charges customers needs a payment layer. The payment provider can collect and process payment details, but the product still needs clear definitions for what is sold, how prices are configured, which confirmed payment or subscription states grant access, and how cancellation and refund requests are handled.

A provider such as Stripe can provide a hosted or embedded checkout instead of requiring a builder to create the entire payment form and payment flow. Stripe is one example, not a required choice. Compare providers based on the countries and payment methods supported, recurring-billing needs, integration model, support, and the operational work the product can realistically maintain.^[21]

Recurring plans add a subscription lifecycle, including incomplete, active, past-due, unpaid, and canceled states. A payment provider can report those changes through webhooks, which are server-to-server events sent to the application. Verify each event, handle duplicate or out-of-order deliveries safely, and update access so a repeated event produces the same final state instead of applying the change twice. Use the confirmed payment or subscription state rather than assuming that a customer returning to a success page proves payment succeeded.^[22][23]

Payment onboarding also depends on who is legally receiving the money. In the United States, Stripe does not require every individual or sole proprietor to form a company or obtain an EIN solely to open an account. Stripe says a U.S. account needs a verifiable taxpayer identification number, but an individual or sole proprietor without an EIN can generally provide an SSN or ITIN. Registered entities commonly provide their legal entity details and EIN. Stripe may also verify business identity, address, website ownership, and payout bank information. Review the provider's current account requirements for the actual business type and country rather than assuming one setup fits everyone.^[24][25][26]

If the product is reaching the point where customers, contracts, and payments require a formal business structure, use the company-foundations section of the scaling guide to identify the formation, ownership, tax-identifier, banking, records, and professional-review questions that may need attention. Formation and tax requirements vary, so confirm the right setup for the business rather than forming an entity only because a software integration appears to expect one.

Infrastructure runs the interface, background tasks, integrations, databases, and observability. The useful early goal is not maximum scale. It is a system that can be deployed predictably, monitored, and changed without creating avoidable downtime.

Separate interactive work from long-running jobs. Put limits on retries. Keep logs that explain failures without collecting unnecessary sensitive information. These choices support both reliability and cost control.

Outside the model layer, common billing meters include requests, execution time, CPU and memory, storage, reads and writes, data transfer, active users, emails, analytics events, logs, and retention. Each provider packages those units differently. Identify the meter, any included allowance, and the expected usage before comparing plans.

Vercel is one way to host and run an application. Amazon Web Services (AWS) and Google Cloud (GCP) offer broader infrastructure options for application code, background work, storage, networking, and other services. AWS Lambda can run event-driven functions, while Google Cloud Run can run containerized services and jobs. Existing cloud accounts, workload length, data-location needs, team familiarity, and the amount of infrastructure control required can influence the choice. An early product rarely needs more than one primary cloud platform.^[19][20]

The support tool may serve individual requests through Vercel Functions. If a team imports fifty requests and closes the tab, a background queue such as Vercel Queues, which Vercel currently labels Beta, could process the batch and retry failed jobs. Because a durable queue can deliver a message more than once, each job should be safe to repeat without duplicating its effects. The application still needs to report progress and surface failures to staff. The model can stay the same while the surrounding system becomes much more important.^[6][7]

On Vercel Pro, included usage is not an automatic traffic cap: additional metered usage can become an on-demand charge. Before public launch, configure Vercel Spend Management, choose a spend amount, keep alerts enabled, and explicitly enable the action that pauses production if that interruption is appropriate for the product. A spend amount alone does not stop usage, the check is periodic rather than instantaneous, and a paused deployment returns a 503 response. Treat it as a billing backstop, then enforce application-level rate limits, request-size and queue limits, caching, and abuse controls as the first line of defense.^[29]

The working environment includes source control, testing, deployment, monitoring, analytics, design, support, and collaboration. Security cuts across every layer. It is not a box added after the stack is complete.

For this support tool, a GitHub repository and GitHub Actions workflow could run tests before changes go live. A simple product dashboard could show how often drafts are edited before approval, while Vercel Observability could help the team spot failed requests. Staff-only order lookups, careful logging, and review of what customer data reaches the model remain separate security responsibilities.^{[8][9][10][11][12]}

Authentication, authorization, secret handling, dependency maintenance, input validation, backups, and incident response all need an owner. The NIST Secure Software Development Framework offers a useful reference for integrating secure practices into the development lifecycle rather than treating them as a final review.^[10][12]

Before every production deployment, review the security of the actual product and confirm which privacy, consumer-protection, intellectual-property, tax, sector-specific, platform, and contractual rules apply to it and to the places where it is offered. Keep public claims specific, truthful, supported by evidence, and consistent with the current product. A cloud, model, analytics, or payment provider does not make the surrounding application secure or compliant on its own; get qualified review when the rules or stakes are unclear.^[10][12][30]

The product's durable value usually lives in its workflow, data model, user relationships, and accumulated learning. Model choices, individual APIs, and implementation techniques may change more often.

Design clear boundaries around the parts you expect to test. Then estimate the cost of each layer against the next milestone, using the approach in How Much Does It Cost to Build an AI Product? That guide turns token use, runtime, storage, events, and other billing meters into illustrative pricing examples and planning ranges. The initial goal is not perfection. It is a system that can keep learning without being rebuilt after every experiment.

The stack is one expression of how you build. To see the broader pattern across your activity and current work, take the 90-second Powdr assessment.