Tines 3B gives automation teams a code-first platform choice

On July 31, 2026, Tines announced Tines 3B as a separate, code-first platform for building, running, and monitoring agents, apps, and automations. The existing visual no-code product is now Tines Stories, and Tines says both products will continue in parallel.

This split gives existing customers a product choice, not a routine AI upgrade. The decision affects who can build a workflow, who can review it, and who can maintain the code, credentials, dependencies, failures, and monitoring after release. This analysis explains when to pilot 3B, keep work in Stories, use both products, or wait.

3B makes code part of the operating responsibility

In 3B, workflows are code. The 3B product page says the platform can connect to APIs or Model Context Protocol (MCP) servers and includes standard Git integration with native branches. Tines's execution documentation says a step can use TypeScript, Python, or shell code. MCP is a standard for connecting AI tools to external systems. A branch is a separate code version that a team can review before approval. Maintainers must review changes, select packages, test runtime changes, and restore an approved version after a failed release.

Tines documents containerized execution for each workflow step, chat experiment, and connection test. A container is a temporary environment that holds code and required software. Each step can define its environment from a Tines 3B base image and run in a fresh, single-use gVisor sandbox, an extra layer between the code and host operating system. Tines also documents durable /storage volumes, standard output as the step result, and standard error as the log. The team still chooses packages, decides which state must last between runs, and tests dependency changes.

Tines says outbound requests pass through an egress proxy, which controls network traffic leaving a step. Its credential proxy documentation says the proxy adds authentication to outgoing requests, limits credentials to verified URL patterns, and centralizes connections. Tines says credentials remain hidden from builders, AI, and workflow code. The customer still approves the application, credential scope, destinations, rotation process, and revocation owner.

Tines says 3B can run in self-hosted, on-premises, or hybrid deployments. Its monitoring covers AI spend, access, duplicate work, estimated value, routes, and dependencies. These controls can make code easier to operate, but each team must confirm which signals appear in its edition and deployment, who reviews them, and what action follows an alert.

A gVisor pull request merged on July 30 adds Tines 3B to gVisor's users page. The change describes gVisor as the isolation boundary for code execution and mentions checkpoint and restore, file-system extensions, and network controls. This supports the existence of the documented architecture. It is not a security certification or an independent assessment of the complete product.

Stories remains the better surface for visual no-code work

Stories remains Tines's visual no-code product for security and IT operations. A team can inspect the workflow on a canvas and change configured actions without adding a source-code repository, package choices, or container builds to its normal process. Tines says no change is required for current Stories customers.

Keep a workflow in Stories when its current owners understand the canvas, credentials, execution history, and exception process, and the work does not need a code toolchain. Moving the same logic into code adds little if every review or repair then needs an engineer. Visual work still needs an owner because a failed connector, changed application field, expired credential, or incorrect condition can stop it.

Pilot 3B only when a team can own the code

3B fits when a team already accepts code review, dependency management, tests, and release recovery as part of automation work. A named maintainer should understand the language, step environment, network access, and systems that receive each action. A reviewer must judge more than whether AI produced code that ran once.

The code-first surface can help when a workflow needs custom libraries, detailed transformations, mixed runtimes, or application behavior that is awkward on a visual canvas. Git and branches can fit an existing engineering review process. This only works if the organization can keep the code current after the original builder changes roles or leaves.

Tines positions 3B as a way for employees to build while IT and security retain controls and visibility. That is vendor positioning. Local review remains necessary for packages, data destinations, external actions, credential scope, tests, and failure behavior. If AI creates the first version, review the generated implementation before approval. Platform controls support that review; they do not decide what the business permits.

Using both works only when each workflow has one home

Using Stories and 3B together can make sense when different work has different maintainers. A team might keep established security and IT automations in Stories while using 3B for code-heavy work that fits an engineering process. Make that division explicit before the second product expands.

Give each workflow one authoritative implementation and one maintenance owner. Record who approves changes, owns the credentials, receives an incident, and decides when to migrate or retire the workflow. Otherwise, parallel products can create duplicates or leave a workflow with nobody prepared to repair it. 3B's duplicate-work monitoring may identify overlap, but the team still decides which version stays active.

Compare one existing automation before changing the portfolio

Use one low-stakes automation that already runs in Stories or another known system. Choose one with stable inputs and outputs, known exceptions, a current owner, and records of normal and failed runs. Keep the required behavior fixed in both surfaces. If the requirements are unclear, resolve them first; builder comparisons cannot repair missing workflow decisions.

Record staff time for the initial build. Then make the same small requirement change in each version. Ask a second person to explain the workflow, review the change, and make a safe correction. Record where that person needed help and which skills were missing.

Use test credentials and a test destination. Verify where each connection is configured, who can change it, how its scope is limited, and how the team revokes it. Cause a controlled failure with an invalid test credential or unavailable test endpoint. Compare the failure signal, evidence for the operator, and time needed to find the affected step.

Restore the last approved version in each product and run the test again. Confirm that the operator can identify the version, distinguish a retry from a new run, and see repeated external actions. Then inspect the monitoring available in the account. In 3B, check whether spend, access, duplicates, value, routes, and dependencies help the owner repair the workflow. In Stories, record the execution and failure evidence the current team uses.

The comparison does not replace production-readiness tests for state, approvals, retries, duplicate-action protection, and longer failures. Our guide to production AI workflow durability and observability explains that separate work.

The pilot should support one of four decisions:

Scroll sideways to see all 2 columns.

Evidence from the comparison	Decision
3B reduces build or maintenance work, and named owners can review code, manage dependencies, protect connections, diagnose failures, and restore a version.	Proceed with a limited 3B rollout for the tested class of work.
Stories is easier for the current owners to explain, change, and recover, while 3B adds a code toolchain without a clear benefit.	Keep that work in Stories.
Each product performs better for a distinct class of workflow, and each class has a clear owner and review process.	Use both, with one authoritative home for every workflow.
A required control, commercial term, deployment option, migration path, or maintenance owner remains unconfirmed.	Wait and set the evidence required for another review.

Commercial terms and operating maturity remain unclear

Tines offers a free Explore plan for 3B and describes it as the equivalent of Community Edition on Tines Stories. Existing customers can also explore 3B at no additional cost. Tines says its pricing approach uses a platform license that covers the full platform rather than separate products or features. The cited material does not provide paid prices, included usage, seat terms, trial terms, or plan limits. Confirm those details before using free access to estimate operating cost.

Migration effort is also unknown. Tines says customers may migrate, adopt 3B beside Stories, or keep their current approach. The cited sources do not establish migration tooling, compatibility, or the work needed to move a specific Story. Long-term portability, detailed commercial terms, and the effects of custom packages or deployment choices need direct confirmation.

The available evidence does not establish independent security or performance results. The gVisor change supports one architectural claim, while Tines's documentation describes the rest of the execution and credential design. Tines reports that employees created more than 500 apps and automations in three weeks. That shows activity inside Tines's rollout, not business value, production quality, or independent adoption. The available Show HN discussion is also a launch signal and includes an engineer who built the product. Mature third-party operation remains unproven.

End the pilot with a product decision

Choose one existing automation, name the people who will build and maintain both versions, and set a review date before work starts. At that review, select one outcome from the table. Do not turn a successful demo into an open-ended migration.

If your team needs help, BaristaLabs can compare one workflow through our process automation service. The work should end with a product decision and named maintenance responsibility, even when the correct choice is the current system.