DEV Community: Bluetick Consultants Inc.

Your iPhone App on the iPhone Duo: What Breaks, What to Fix, and What It Costs

Bluetick Consultants Inc. — Wed, 16 Sep 2026 09:50:51 +0000

Published: 16 September 2026 | Updated: 16 September 2026

Short answer: To prepare your app for iPhone Duo, rebuild it with the iOS 27.1 SDK before the phone goes on sale on October 23. Apps built with older SDKs keep working, but they sit boxed in black space on both screens.

Bottom line: Fix orientation-based layouts, UIScreen.main calls and equal-margin maths first. Apple’s fees are trivial; engineering and testing time is the real cost, ranging from a few hours for iPad-ready apps to several days for phone-only apps.

On October 23, some of your most valuable customers will open your app on a phone that costs $1,999 and folds in half. If nobody has touched the app in a while, it will not crash. It will do something arguably worse. It will sit in a box in the middle of a 7.6-inch screen, black space all around it, looking like it was made for a different phone. Which, to be fair, it was.

Nobody files a bug report about this. Instead, people just notice that Netflix fills the screen and your app does not, and they draw their own conclusions about which company is paying attention.

That is the real risk with Apple’s first foldable. The app keeps working. It just looks abandoned, on an iPhone with the highest starting price Apple has ever charged, held by the kind of people who tend to pay for apps.

What we’re solving

The goal here is narrow: get an existing iPhone app to look deliberate on both of the iPhone Duo’s screens, in every way people will hold it. Closed, it is a 5.4-inch phone. Open, it is a 7.6-inch small tablet. Both screens have roughly a 1.4:1 shape, which is much squarer than any iPhone before it. A regular iPhone held sideways is closer to 2.17:1. So neither screen is a shape your layouts have seen.

The phone ships with iOS 27.1. Pre-orders open October 16, and it goes on sale October 23.

How much of the screen you get depends on how you last built the app

Apple has set up three tiers. Which one your app lands in depends on the SDK, meaning the version of Apple’s developer toolkit the app was last compiled with. First, moving up a tier starts with rebuilding against a newer SDK. Apple’s developer session also covers opting in to the full-screen experience, and making good use of the extra space is a separate job again.

Last built with	What happens on the Duo	How it looks
An SDK older than iOS 27	Runs in a compatibility box, with black filling the rest. This happens on both screens, not just the inner one.	Clearly unoptimized
iOS 27 SDK (Xcode 27)	On the inner screen, the app extends into the space beside the status bar but stops short of the edge.	Acceptable, some dead space
iOS 27.1 SDK (Xcode 27.1)	Reaches the screen edges. Standard navigation and toolbar buttons move to the side, laid out vertically.	What Apple showed on stage

Two things the early headlines got wrong

Xcode 27.1 is not out yet. Some coverage said the new Xcode, with its iPhone Duo simulator, is already available. As of today, Apple’s own Get Ready for iPhone Duo page lists the Xcode 27.1 beta as “coming later this month.” Apple’s developer videos demo the simulator, but you cannot download it. That changes the planning maths. With launch on October 23, most teams will get a few weeks with the simulator, not six.

The outer screen does not rescue old apps. Early reports suggested older apps would look fine when the phone is closed. The outer screen is not shaped like any earlier iPhone, and legacy builds are boxed on both displays. If your plan was to rely on people using the phone closed, drop it.

Out of scope for this post: Apple Pencil support (Apple says it arrives later in 2026), the Duo-only camera features, and iPad-only apps.

A real example

Netflix is the clearest case so far. Apple worked with it before launch and put it on stage, alongside Zoom, Slack and a few others. What Netflix did is worth studying because it goes past “fill the screen.”

One activity, two screens. You can scroll the short Clips feed on the outer screen, then open the phone and carry on in the same place on the big one.
The half-open pose has its own layout. Stand the phone up like a tiny laptop and the video stays on the top half while the playback controls drop to the bottom half.
Zoom took a similar line. On the inner screen, it shows the shared content and the other participants together, instead of making you pick one.

However, keep this in proportion. That is a handful of large companies with early access and Apple engineers on call. It is not evidence that the wider App Store is ready.

We have seen this film before. When the taller iPhone 5 arrived in 2012, apps that had not been updated ran with black bars at the top and bottom. When the iPhone X arrived in 2017, apps not rebuilt for iOS 11 were letterboxed the same way. Both times, the bars became the quickest way for users to spot an abandoned app. Similarly, Instagram went well over a decade without a proper iPad app, leaving iPad owners with a blown-up phone app. The Duo raises the stakes, because the device exposing the neglect is the phone people carry every day.

How it works (with code)

In fact, most of this is not new work. Apple has been pushing developers toward flexible layouts for years, through size classes, safe areas and resizable iPad windows. If your app already behaves well on an iPad in Split View, you are most of the way there. If your app was built for “an iPhone,” singular, you have a list.

The habits that break on a folding iPhone

Choosing the layout by orientation. The inner screen ignores the orientations your app says it supports. A portrait-only app will not stay portrait-only once the phone is open. Apple’s advice is to decide layout by size class instead. Size classes are Apple’s way of describing available space as “compact” or “regular.” The outer screen behaves like a normal iPhone. The inner one, by contrast, is regular in both directions, like an iPad.
Asking for “the main screen”. Code that calls UIScreen.main assumes there is one screen. There are now two, and Apple says this API will be deprecated. Instead, get the screen from the window the app is actually in.
Assuming the margins are equal. The status bar and camera now sit in a corner, so the safe area is often wider on one side than the other. Any maths that doubles the left inset to get the usable width will be wrong.
*Hand-built navigation bars. * Apple’s standard navigation components adapt on their own, and can show a sidebar on the inner screen with one setting. In contrast, custom bars can collide with system elements. iOS 27.1 adds reserved regions (ReservedRegion in SwiftUI, UIViewReservedRegion in UIKit) so custom controls can take space without overlapping the system’s.
Forgetting the in-between states. For example, Split View gives your app half the inner screen with uneven margins. In the half-folded pose, controls need to stay clear of the crease. These in-between states are where most layout bugs will hide.
Assuming a big screen means no black bars on video. A 1.4:1 screen is close to the IMAX shape, so standard widescreen video still shows bars, just at the top and bottom instead of the sides. Good video apps will use that space for controls or information, the way Netflix does.

What the fix looks like

Here are two of the most common fixes, adapted from Apple’s “Prepare your app for iPhone Duo” session. The before lines assume one screen and symmetric margins. The after lines ask the system instead.

// Before: assumes one screen and equal margins
let scale = UIScreen.main.scale
let width = view.bounds.width - view.safeAreaInsets.left * 2

// After: asks the current window and handles each side
let scale = traitCollection.displayScale
let width = view.bounds.inset(by: view.safeAreaInsets).width

A small audit script to size the job before the simulator arrives

Since nobody can run the Duo simulator yet, the useful thing to do this week is estimate. The script below scans an iOS codebase for the patterns above and prints each suspect line with a plain-English fix. Run it from your project folder with python3 duo_audit.py path/to/YourApp.

import re, sys, pathlib

# Habits Apple's iPhone Duo guidance warns about, with a plain fix
RULES = [
    (r"UIScreen\.main",
     "Two screens now. Get the screen from the window scene."),
    (r"UIDevice\.current\.orientation|supportedInterfaceOrientations",
     "Inner display ignores orientation locks. Use size classes."),
    (r"safeAreaInsets\.(left|right)\s*\*\s*2",
     "Assumes equal left/right insets. Duo insets are uneven."),
    (r"userInterfaceIdiom\s*==\s*\.phone",
     "Duo is still a phone. Don't guess screen size from it."),
    (r"width:\s*(375|390|393|402|414|428|430|440)\b",
     "Hard-coded iPhone width. Let the layout flex."),
]

def audit(root):
    hits = 0
    for path in sorted(pathlib.Path(root).rglob("*.swift")):
        lines = path.read_text(errors="ignore").splitlines()
        for n, line in enumerate(lines, 1):
            for pattern, advice in RULES:
                if re.search(pattern, line):
                    hits += 1
                    print(f"{path.name}:{n} {line.strip()}")
                    print(f" -> {advice}")
    print(f"\n{hits} possible iPhone Duo layout issue(s) found.")

audit(sys.argv[1] if len(sys.argv) > 1 else ".")

Output on a two-file sample project:

HomeView.swift:6 .frame(width: 393)

-> Hard-coded iPhone width. Let the layout flex.

PlayerViewController.swift:6 let scale = UIScreen.main.scale

-> Two screens now. Get the screen from the window scene.

PlayerViewController.swift:7 let usable = view.bounds.width – view.safeAreaInsets.left * 2

-> Assumes equal left/right insets. Duo insets are uneven.

PlayerViewController.swift:8 if UIDevice.current.orientation.isLandscape {

-> Inner display ignores orientation locks. Use size classes.

4 possible iPhone Duo layout issue(s) found.

What it does: reads every Swift file, checks each line against five risky patterns, and prints the file, the line and what to do about it.
Why it helps: four hits in two files is an afternoon. Four hundred hits across a large app is a sprint, and you want to know that before October, not after.
What it is not: a compiler or a test. It flags suspects by text matching, so expect some false alarms, and it will miss layouts that are wrong for other reasons. Treat the count as a sizing signal, then confirm everything in the simulator.

In addition, Apple is shipping its own help. Xcode 27.1 includes a coding skill Apple calls App Resizability, an updated version of the modernization skill it introduced for UIKit apps this year, now covering SwiftUI and the Duo.

What it costs

The money Apple charges is almost nothing. The Apple Developer Program is $99 a year, which you are already paying if your app is on the App Store. Likewise, Xcode and the simulator are free. A real iPhone Duo for testing starts at $1,999, but most teams will not have one before launch day anyway.

The real cost, however, is engineering and testing time. Early developer write-ups put the work at a few hours for a well-built app that already handles iPad, and several days plus testing for a phone-only app with hand-coded layouts. The other ranges below are our estimates, based on those figures and on past iPhone screen changes. Prices were checked on September 11, 2026.

Cost options compared

Option	Upfront cost	Ongoing cost	Hidden costs	Best for
Do nothing	$0	$0	App looks boxed-in on both screens, next to competitors that don’t	Apps in maintenance mode with few iPhone users
Rebuild with the iOS 27 SDK only	About 1-2 days of rebuild and regression testing (estimate)	Normal release cycle	Still leaves dead space on the inner screen	Teams already shipping an iOS 27 update
Adopt iOS 27.1, mostly standard UI	A few hours to a few days	More QA per release	Test matrix grows; no real device until Oct 23	Apps built on Apple’s standard navigation
Adopt iOS 27.1, heavily custom UI	Several days to a few weeks (estimate)	Ongoing layout upkeep	Custom bars and players need rework; design time	Media, camera, games, custom design systems
Build Duo-specific features	A product project; depends on scope	Feature maintenance	Design and product time for a small early audience	Video, conferencing, reading, productivity

The hidden cost: a bigger test matrix

One hidden cost applies to every option except the first. The testing matrix grows for good: two screens, two orientations on each, the half-folded pose and Split View. For a solo developer that might be an extra hour per release. On the other hand, for a team with a formal QA cycle, it needs to be written into the test plan now.

Pros and cons

In favour of doing the work now

A valuable audience. People who pay $1,999 for a phone are, on average, more willing to pay for apps. Being polished on day one is cheap marketing.
The work carries over. Flexible layout that fixes the Duo also improves your app on iPad, in resizable windows, and when mirrored to a Mac. This is not a one-device project.
Apple’s standard components do much of it for you. Apps built on standard navigation get the sidebar and the side-mounted controls largely for free after a rebuild.
The cost of entry is low. The tooling is free, and for tidy codebases the job is measured in hours.

Against, or at least against rushing

The audience is small at first. Even Apple-focused press expects the Duo to be niche to start. For most apps, standard iPhones will be almost all of the traffic for a long while.
The timeline is tight. The simulator is still weeks away and real hardware arrives on launch day. In other words, everything before October 23 is testing on a simulator.
The testing burden is permanent. As a result, every future release has more screens and states to check.
It is a first-generation platform. Apple’s written guide to preparing apps is still marked as coming. Expect the advice to shift once real people start using the phone.
The honest objection. For an app people open for thirty seconds to pay for parking, a boxed-in compatibility view is ugly but perfectly usable. Consequently, spending a sprint on it may never pay back. Fix the cheap things, rebuild, and move on.

Key takeaways

Old iPhone apps will not break on the iPhone Duo. They will look boxed-in on both screens, and users will read that as neglect.
The SDK you build with decides how much screen you get. Edge-to-edge needs the iOS 27.1 SDK.
As of September 11, the Xcode 27.1 beta is not out yet. Apple says later this month, and the phone ships October 23, so audit your code now and test the moment it lands.
The biggest code risks are orientation-based layout, references to the main screen, equal-margin maths and custom navigation bars.
Apple’s fees are trivial. Engineering and testing time is the real budget, and most of that work also improves your app on iPad and Mac.
Prioritise by audience. Video, conferencing and productivity apps should move first; short-session utility apps can rebuild and wait.

Frequently asked questions

What happens to an old iPhone app on the iPhone Duo?

It keeps working, but apps last built with an SDK older than iOS 27 run in a compatibility box with black space around them, on both the outer and inner screens.

Which SDK do I need for my app to fill the iPhone Duo screen?

The iOS 27.1 SDK, which ships with Xcode 27.1. Building with the iOS 27 SDK extends the app on the inner screen but still leaves dead space at the edge.

Is the Xcode 27.1 beta with the iPhone Duo simulator available yet?

Not as of September 16, 2026. Apple’s Get Ready for iPhone Duo page lists the Xcode 27.1 beta as coming later this month. The iPhone Duo goes on sale October 23.

What code patterns break on the iPhone Duo?

The biggest risks are choosing layout by orientation instead of size class, calling UIScreen.main, assuming equal left and right safe-area margins, and hand-built navigation bars that can collide with system elements.

How long does it take to prepare your app for iPhone Duo?

Early developer write-ups put it at a few hours for a well-built app that already handles iPad, and several days plus testing for a phone-only app with hand-coded layouts. Heavily custom interfaces can take several days to a few weeks.

Does preparing for the iPhone Duo cost anything beyond engineering time?

Very little. The Apple Developer Program is $99 a year, which published apps already pay, and Xcode and the simulator are free. The real cost is engineering time and a permanently larger testing matrix.

The post Your iPhone App on the iPhone Duo: What Breaks, What to Fix, and What It Costs appeared first on Bluetick Consultants Inc..

Database Indexing in Ruby on Rails: When, Why, and How

Bluetick Consultants Inc. — Thu, 10 Sep 2026 17:53:11 +0000

Published: 10 September 2026 | Updated: 10 September 2026

Key takeaway: Rails database indexing is often the highest-impact fix for slow queries once N+1 problems are solved. Index the queries you actually run: composite indexes for multi-column filters, partial indexes for the small slice of rows you query most, and algorithm: :concurrently for large production tables. Verify every index with EXPLAIN ANALYZE, because each extra index adds cost to every write.

Who This Guide Is For

This guide is for Ruby on Rails developers, backend engineers, and engineering leads who run PostgreSQL in production and need to decide which indexes to add, change, or remove. It assumes you’re comfortable with ActiveRecord and migrations, but not that you’re a database specialist.

When to Use This Advice

Use the techniques in this guide when:

A page, report, or API endpoint is slow, and EXPLAIN ANALYZE shows a Seq Scan on a large table.
Database CPU spikes during peak traffic while your application servers have spare capacity.
A table has grown from thousands of rows to millions, and queries that were once instant now take seconds.
You need to add an index to a live production table without blocking writes.
Write latency is creeping up, and you suspect unused or overlapping indexes.

Indexing is the wrong fix in two cases. On small tables, a sequential scan is often faster than an index lookup. And if a page fires hundreds of small queries, fix the N+1 problem first, because no index can fix that pattern.

Use Cases This Guide Covers

SaaS dashboards and reporting: composite indexes for multi-column filters, as in the case study where an 8-second report dropped to under 500 milliseconds.
E-commerce and order management: fast lookups by customer, order status, and date.
Soft deletes and archived records: partial indexes that cover only the active rows you actually query.
High-traffic APIs: unique indexes on email addresses, UUIDs, and external IDs.
Production schema changes: concurrent index builds on large tables with zero downtime.

These patterns apply across SaaS, e-commerce, fintech, and logistics platforms, or any Rails application where data grows faster than caching can keep up.

“A single well-designed index can reduce a query from several seconds to a few milliseconds. But a poorly designed indexing strategy can slow down every write operation in your application.”

As Ruby on Rails developers, we spend a lot of time optimizing ActiveRecord queries, eliminating N+1 queries, and adding caching layers. Yet one of the most impactful performance improvements often happens below the Rails application—in the database itself.

Whether you’re building a SaaS platform, an e-commerce application, or an API that serves millions of requests, your database eventually becomes the bottleneck. When that happens, adding more application servers rarely solves the problem. Instead, the answer is often a better indexing strategy.

In this article, we’ll cover:

What database indexes are
How indexes work internally
Different types of indexes
Partial indexes
Composite indexes
Zero-downtime indexing in production
Drawbacks of excessive indexing
Real-world Rails examples
Best practices for production applications

Understanding How Databases Search Data

For example, imagine you have a library with five million books.

When someone asks for a book by its title, there are two approaches.

Without an Index

First, the librarian starts from shelf one.

Book 1

↓

Book 2

↓

Book 3

↓

…

↓

Book 5,000,000

Eventually the book is found.

In fact, this is exactly what databases call a Sequential Scan (Seq Scan).

With an Index

Instead of checking every shelf, the librarian opens the catalogue.

Harry Potter → Shelf 18

Rails Guide → Shelf 42

Ruby Cookbook → Shelf 81

As a result, the book is found immediately.

In other words, that catalogue is essentially what a database index is.

What Exactly is an Index?

An index is a special data structure maintained by the database that stores values from one or more columns in a sorted format, along with pointers to the corresponding table rows.

Most relational databases such as PostgreSQL and MySQL use a B-Tree (Balanced Tree) as the default index type.

Instead of scanning every row, the database traverses the tree.

           Root

          /      \

      A-M          N-Z

     /  \         /   \

  Adam Bob    Mike Zack

Searching becomes logarithmic rather than linear.

Instead of checking five million rows, the database checks only a few levels of the tree.

Working Example

For instance, suppose we have this model.

class Customer < ApplicationRecord
end
Schema:
create_table :customers do |t|
  t.string :name
  t.string :email
  t.string :city
  t.string :status
end

Additionally, the application frequently executes:

Customer.find_by(email: "john@example.com")

Without an Index

SQL executed:

SELECT *
FROM customers
WHERE email='john@example.com';

Execution plan:

Seq Scan on customers

Consequently, the database checks every row.

With 5 million records:

Row 1

↓

Row 2

↓

Row 3

↓

…

↓

Row 5,000,000

Adding an Index

Migration:

class AddEmailIndexToCustomers < ActiveRecord::Migration[7.1]
  def change
    add_index :customers, :email
  end
end

Run:

rails db:migrate

Afterward, the query changes dramatically.

Execution plan:

Index Scan

Instead of scanning the table, PostgreSQL looks inside the index.

Email Index

adam@example.com

↓

john@example.com

↓

mary@example.com

Therefore, query execution becomes almost instantaneous.

Composite Indexes

Similarly, suppose every dashboard request executes:

Order.where(
  customer_id: current_customer.id,
  status: "completed"
)

Bad approach:

add_index :orders, :customer_id
add_index :orders, :status

Better:

add_index :orders,
          [:customer_id, :status]

Now PostgreSQL can answer the query using a single index lookup instead.

Partial Indexing

This is one of the most underused yet powerful indexing techniques in PostgreSQL.

For example, suppose your application uses soft deletes.

Customer.where(deleted_at: nil)

If 95% of your rows are deleted, why should PostgreSQL index them?

Instead:

add_index :customers,
          :deleted_at,
          where: "deleted_at IS NULL"

Thus, the index now contains only active customers.

Benefits:

Smaller index
Less storage
Faster lookups
Faster writes

Partial Index vs Regular Index

Example

Regular index

add_index :customers, :status

Indexes:

Active

Inactive

Pending

Deleted

Archived

Partial index

add_index :customers,
          :status,
          where: "status='Active'"

Indexes only:

Active

Achieving Zero Downtime While Adding Indexes

In particular, one mistake developers make is running:

add_index :customers, :email

On a table with millions of rows, PostgreSQL may lock the table while building the index, blocking reads or writes depending on the operation.

Rails supports concurrent index creation for PostgreSQL.

class AddEmailIndex < ActiveRecord::Migration[7.1]
  disable_ddl_transaction!

  def change
    add_index :customers,
              :email,
              algorithm: :concurrently
  end
end

Why `disable_ddl_transaction!`?

Specifically, PostgreSQL cannot create indexes concurrently inside a transaction. Rails wraps migrations in transactions by default, so you must disable it.

Benefits

No long table lock
Reads continue
Writes continue
Safe for production deployments

For this reason, this is the recommended approach for large production databases.

Verifying the Index

Above all, never assume the database is using your index.

Run:

EXPLAIN ANALYZE
SELECT *
FROM customers
WHERE email='john@example.com';

Before indexing:

Seq Scan

After indexing:

Index Scan

Sometimes PostgreSQL still chooses a sequential scan if it estimates that scanning the table is cheaper, especially for very small tables or low-selectivity queries.

The Hidden Cost of Too Many Indexes

Still, many developers think:

More indexes = Faster database.

However, that’s not true.

Every index must also be updated whenever data changes.

For instance, imagine this insert:

Customer.create(...)

Without indexes:

Insert Row

With eight indexes:

Insert Row

↓

Update Index 1

↓

Update Index 2

↓

Update Index 3

↓

…

↓

Update Index 8

In short, every additional index increases write overhead.

Drawbacks of Excessive Indexing

Slower INSERT operations
Slower UPDATE operations
Slower DELETE operations
Increased storage usage
Longer backup times
Longer restore times
Increased VACUUM maintenance in PostgreSQL
More memory consumed by indexes

Hence, indexing should always be driven by actual query patterns, not guesswork.

Production Case Study

In one of our production reporting systems, a dashboard loaded customer reports filtered by:

Customer ID
Reporting Group
Status

Initially, the table had individual indexes on each column. The query planner still had to combine results, leading to response times of over 8 seconds.

We analyzed the execution plan using EXPLAIN ANALYZE and replaced the individual indexes with a composite index matching the query pattern:

add_index :reports,
          [:customer_id, :reporting_group_id, :status],
          algorithm: :concurrently

Because the migration used algorithm: :concurrently and disable_ddl_transaction!, it was deployed to production without blocking application traffic.

Overall, the results were significant:

Response time dropped from 8 seconds to under 500 milliseconds
Database CPU usage decreased during peak traffic
No application code changes were required

Finally, this reinforced an important lesson: understanding how your application queries data is often more valuable than adding hardware.

Best Practices

Index foreign keys used in joins.
Use unique indexes for unique columns like email and UUIDs.
Prefer composite indexes for common multi-column filters.
Use partial indexes when only a subset of rows is queried frequently.
Create indexes concurrently in production to avoid downtime.
Validate index usage with EXPLAIN ANALYZE.
Remove unused indexes periodically.
Monitor slow query logs and index bloat.

Frequently Asked Questions

When should I add a database index in Rails?

Add an index when a column appears in frequent WHERE, JOIN, or ORDER BY clauses on a table large enough for sequential scans to hurt. Foreign keys, unique fields such as email, and columns behind slow dashboard filters are the usual candidates. Confirm the need with EXPLAIN ANALYZE rather than indexing speculatively.

What is the difference between a composite index and a partial index?

A composite index covers several columns in one index, such as customer_id and status, and serves queries that filter on those columns together. It works best when the query filters on the leading column. A partial index covers only rows matching a condition, such as active records, which keeps it smaller and cheaper to maintain.

Does add_index lock the table in PostgreSQL?

A standard add_index runs CREATE INDEX, which blocks inserts, updates, and deletes on the table until the build finishes, while reads continue. On large production tables, use algorithm: :concurrently with disable_ddl_transaction! so writes keep flowing. If a concurrent build fails, drop the leftover invalid index before retrying.

Why is PostgreSQL not using my index?

The planner skips an index when it estimates a sequential scan is cheaper, which is common on small tables or when a query matches a large share of rows. Stale statistics, or conditions that don’t match the index’s leading column or partial-index predicate, can also cause it. Run ANALYZE, then check the plan with EXPLAIN ANALYZE.

Can too many indexes slow down a Rails application?

Yes. Every index must be updated on each insert, update, and delete, so unused indexes add write latency, storage, and VACUUM work without speeding up reads. Review pg_stat_user_indexes periodically and drop indexes with an idx_scan count of zero, after confirming they don’t back a unique constraint.

Final Thoughts

Database indexing is one of the highest-impact optimizations you can make in a Rails application. But the goal isn’t to add indexes everywhere—it’s to create the right indexes for the queries your application actually executes.

In conclusion, by combining thoughtful indexing, query analysis, and zero-downtime deployment techniques, you can build Rails applications that continue to perform well as your data grows from thousands to millions of records.

The post Database Indexing in Ruby on Rails: When, Why, and How appeared first on Bluetick Consultants Inc..

Beyond the Chatbot: What the New Digital Coworkers Actually Do, and What They Cost

Bluetick Consultants Inc. — Thu, 03 Sep 2026 14:42:03 +0000

Published: 3 September 2026 | Updated: 3 September 2026

The short answer: Agentic AI digital coworkers can now operate software that offers no other way in, by looking at the screen and clicking. Two credible products launched in August 2026 – Grok Bot from xAI and Warmwind OS from Warmwind AG. Agentic AI cost is unpredictable by design: Warmwind was listed at 1 euro per worker hour, Grok Bot has no standalone price and bills overflow by the token. Reliability is the harder problem. At 85 percent accuracy per step, a ten-step job finishes cleanly about one time in five. Gartner expects over 40 percent of agentic AI projects to be cancelled by the end of 2027. Use these tools for short, bounded jobs with a checkable result – not long unattended chains.

The problem

You asked an AI chatbot to help you with your expense claims. It wrote you a lovely set of instructions. Then you went and did all the clicking yourself.

That is the shape of the complaint. The assistant is clever, and it is also sitting on its hands. It can tell you what to do, draft the email, explain the spreadsheet formula. It cannot open your accounting software, find last month’s invoices, and file them. So the boring part, the part that eats the afternoon, still lands on you.

The gap has a simple cause. Most AI tools are built to answer, then stop. Every step needs you to come back and ask again. If a job has thirty steps, you are the one carrying it between them.

What we are solving

A new kind of product tries to close that gap. Instead of answering and stopping, it gets its own computer in the cloud and works on the job in the background.

It has a screen, a keyboard and a mouse, just like you do, plus its own web browser and file storage.
You give it a whole task, not a single question. Something like: pull last week’s orders, check them against the invoices, and flag the mismatches.
It keeps going while your laptop is shut. The work happens on a machine in a data centre, not on your desk.
It comes back to you when it needs a decision, a password, or permission to send something.

The industry calls these agents, digital coworkers, or cloud employees. The plain version: software that does the clicking instead of describing it.

Two things this does not solve, and they matter more than the marketing suggests:

It does not remove the need to check the work. Someone still reviews what came out, especially for anything involving money or customers.
It does not make a messy process tidy. If your current workflow only works because a human quietly fixes things, handing it to an agent hands over the mess too.

A real example

Two products launched within a fortnight of each other in August 2026, and they take noticeably different routes to the same idea.

Grok Bot, from xAI

Launched in beta on 11 August 2026, then widened across subscription plans through the rest of the month.
Each user gets one persistent cloud computer with a browser, a filesystem and a terminal. Your bots share it.
It prefers a proper connection to an app where one exists, and falls back to driving the screen only for tools that offer no clean way in. This matters: it is a hybrid, not a pure screen-driver.
You can show it a job once by recording a browser session of up to ten minutes, and it saves that as a routine it can repeat on a schedule.
It runs on macOS, Windows and iPhone. There is no Linux, Android or iPad version at launch.

Warmwind OS, from Warmwind AG in Jena, Germany

Version 1.0 launched publicly on 26 August 2026, after a closed beta with a waitlist reported at over 12,000 people.
This one is the pure screen-driver. Each worker gets a Linux desktop in the cloud and operates ordinary software by looking at the screen and using a mouse and keyboard. No integrations required.
That is the whole pitch: it can drive old, ugly business software that has no modern way to connect to it. The launch video demonstrates exactly that, on legacy German rental-management software.
The company runs on German cloud infrastructure and leans hard on European data-protection rules as a selling point, which matters to firms that cannot send recordings of their screens to an American provider.

Both companies use the phrase visual navigation. Only Warmwind, however, means it literally for everything. Judge each on which of your tools it can actually reach, because that is where the difference shows up.

How it works, and the maths that decides whether it helps

The mechanics are less interesting than the arithmetic. An agent working through a long job has to get every step right in a row. As a result, small error rates compound fast.

How reliable is a multi-step AI agent?

Here is the calculation. It is short enough to read and you can run it yourself:

"""How often does a multi-step agent finish a whole job correctly?"""


def end_to_end(step_accuracy, steps):
    """Chance all steps succeed in a row, as a percentage."""
    return step_accuracy**steps * 100


def steps_before_coinflip(step_accuracy):
    """How many steps until the job is likelier to fail than succeed."""
    steps = 1
    while end_to_end(step_accuracy, steps) >= 50:
        steps += 1
    return steps


for accuracy in (0.85, 0.95, 0.99):
    print(f"\nAgent is {accuracy:.0%} accurate on each single step:")
    for steps in (5, 10, 20, 50):
        clean = end_to_end(accuracy, steps)
        print(f" {steps:>2} steps -> {clean:5.1f}% finish clean")
    print(f" coin flip at {steps_before_coinflip(accuracy)} steps")

Running it prints this:

Agent is 85% accurate on each single step:
   5 steps -> 44.4% finish clean
  10 steps -> 19.7% finish clean
  20 steps -> 3.9% finish clean
  50 steps -> 0.0% finish clean
  coin flip at 5 steps

Agent is 95% accurate on each single step:
   5 steps -> 77.4% finish clean
  10 steps -> 59.9% finish clean
  20 steps -> 35.8% finish clean
  50 steps -> 7.7% finish clean
  coin flip at 14 steps

Agent is 99% accurate on each single step:
   5 steps -> 95.1% finish clean
  10 steps -> 90.4% finish clean
  20 steps -> 81.8% finish clean
  50 steps -> 60.5% finish clean
  coin flip at 69 steps

What those numbers mean in practice

In plain words, for anyone who skipped the code:

An agent that gets 85 out of 100 individual clicks right finishes a ten-step job cleanly about one time in five.
Push it to 95 out of 100 and the same ten-step job works about six times in ten. Better, still not something you would leave unwatched.
You need roughly 99 out of 100 before long jobs hold together, and even then a fifty-step job fails about four times in ten.
This is why the demos look magical and the rollouts disappoint. A demo is a short job. Your actual work is a long one.

It also tells you how to use these tools well. Short, bounded jobs with a checkable result are where they pay off. Long unattended chains, by contrast, are where they quietly burn money.

What it costs

Prices below were checked on 2 September 2026. This corner of the market is repricing constantly, so treat these as a starting point and confirm before you buy.

Option	Upfront cost	Ongoing cost	Hidden costs	Best for
Carry on as you are	None	None in cash	The hours themselves. Work that only one person knows how to do.	Anyone whose repetitive work is under a few hours a week
Grok Bot (xAI)	None	No standalone plan. Bundled into SuperGrok Plus and Heavy, and Cursor Pro Plus, Ultra and Teams tiers. Plans include a weekly allowance.	Usage past the allowance is billed from model and token cost. Grok 4.6 runs $2 per million input tokens and $6 per million output, doubling above 200k tokens. Reports say there is no product-specific spend cap yet.	Individuals already paying for one of those plans
Warmwind OS	None	Listed at 1 euro per hour of worker time when checked on 27 August 2026, with a launch promotion at half price.	Idle time still counts as worker time. Screen-driven runs are slower than direct connections, so the same job burns more minutes.	Smaller firms with old software and European data rules to satisfy
Traditional RPA (UiPath and similar)	Consultant setup, often weeks	Per-licence, quoted by sales	Breaks whenever a screen layout changes. Needs someone on staff to maintain it.	Large, stable, high-volume processes

Three things to take from the table:

Nobody publishes a number you can plan against. Warmwind gives an hourly rate but the hours depend on how slow the screen work is. Grok Bot gives no separate price at all, only an allowance inside a bundle.
Hourly and token billing means the bill scales with how badly the agent struggles. A job that goes wrong twice costs three times as much as one that works.
Even so, free trials do not tell you the running cost. The published guidance is to treat the first month as an experiment, not a budget line.

Pros and cons

What genuinely works

Reaches software that has no other way in. This is the real advance. Old systems that no integration ever supported can now be driven.
Setup is also quick. No consultant, no integration project. You describe the job or record yourself doing it once.
Work continues without you. Overnight jobs finish while your machine is off.
Teaching by demonstration is far easier than writing rules, and it is how both products expect you to start.

What genuinely does not

Reliability compounds badly, as the numbers above show. This is the central limitation and no vendor has solved it.
Screen-watching is also fragile by nature. A redesigned page, a pop-up, a slow load, or an unexpected login prompt can derail a run that worked yesterday.
Costs are hard to predict and, in at least one case, hard to cap.
Weak isolation between agents. xAI’s own documentation states the cloud computer belongs to your account rather than to each bot, and warns explicitly against using separate bots as a security boundary. Logins and files are shared across all of them.
The analyst forecasts point the other way from the hype. Gartner expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, citing runaway costs, unclear value and weak risk controls. Surveys through 2026 repeatedly found most pilots never reaching production.

On that last point, one correction to a claim you will see everywhere. 2027 is being sold as the year these tools take over. The evidence available today points instead to 2027 being the year the weaker projects get cancelled. Both things can be true: the technology is real and improving, and most attempts to deploy it will still fail. Pick your jobs accordingly.

Key takeaways

These tools are genuinely new in one respect: they can operate software that offers no other way in, by looking at the screen and clicking.
Two credible products launched in August 2026. Warmwind OS drives the screen for everything. Grok Bot prefers a direct connection and only drives the screen when it must.
Reliability compounds. At 85 percent per step, a ten-step job finishes cleanly about one time in five. Short, checkable jobs are where these tools earn their keep.
Costs are unpredictable by design. Warmwind was listed at 1 euro per worker hour in late August 2026. Grok Bot has no standalone price and bills overflow usage by the token.
Nobody has solved supervision. Budget for someone to check the output, and do not point an agent at anything expensive without an approval step.
Gartner expects over 40 percent of agentic AI projects to be cancelled by the end of 2027. Start with one small job you can verify, not a department-wide rollout.

Frequently Asked Questions

What is an agentic AI digital coworker?

It is software that gets its own computer in the cloud, with a browser, filesystem and

screen, and completes a whole multi-step task rather than answering a single question. It works

in the background while your own machine is off, and returns to you when it needs a decision, a

password or permission to send something.

How much does agentic AI cost in 2026?

Neither major product publishes a number you can plan against. Warmwind OS was listed at 1

euro per hour of worker time when checked on 27 August 2026, with a launch promotion at half

price. Grok Bot has no standalone plan at all; it is bundled into SuperGrok Plus and Heavy and

Cursor Pro tiers with a weekly allowance, and overflow usage is billed at Grok 4.6 token rates

of 2 dollars per million input tokens and 6 dollars per million output. Because billing is

hourly or per token, the bill scales with how badly the agent struggles.

Why do agentic AI agents fail on long tasks?

Accuracy compounds across steps. An agent that is 85 percent accurate on each individual step

finishes a ten-step job cleanly only about one time in five, and reaches a coin flip at five

steps. At 95 percent accuracy a ten-step job works about six times in ten. You need roughly 99

percent per step before long jobs hold together, and even then a fifty-step job fails about four

times in ten. This is why demos, which are short jobs, look magical while real rollouts

disappoint.

Should we choose Grok Bot or Warmwind OS?

Judge each on which of your tools it can actually reach. Grok Bot is a hybrid: it prefers a

proper connection to an app where one exists and drives the screen only as a fallback, and it

runs on macOS, Windows and iPhone with no Linux, Android or iPad version at launch. Warmwind OS

is a pure screen-driver on a cloud Linux desktop, needs no integrations, and is the stronger fit

for old business software and for firms bound by European data-protection rules.

Is 2027 the year agentic AI takes over?

The evidence available today points the other way. Gartner expects more than 40 percent of

agentic AI projects to be cancelled by the end of 2027, citing runaway costs, unclear value and

weak risk controls. Both things can be true at once: the technology is real and improving, and

most attempts to deploy it will still fail. Start with one small job you can verify rather than

a department-wide rollout.

What does agentic AI not solve?

Two things. It does not remove the need to check the work, especially where money or

customers are involved, so budget for a human reviewer and an approval step. And it does not

make a messy process tidy: if a workflow only works because a person quietly fixes things,

handing it to an agent hands over the mess too.

The post Beyond the Chatbot: What the New Digital Coworkers Actually Do, and What They Cost appeared first on Bluetick Consultants Inc..

AI-native SDLC in a regulated, multi-vendor delivery estate

Bluetick Consultants Inc. — Wed, 26 Aug 2026 19:10:05 +0000

Published: 26 August 2026 | Updated: 27 August 2026

TL;DR – The short answer: the artifact chain is the right spine, and the playbook just starts one stage too late and assumes one company owns the whole chain. Two things break when you run an AI-native SDLC in BFSI. Intent doesn’t arrive clean: work enters through eight different doors and one tech lead is already translating it in his head, so that translation has to become a committed artifact before Plan. And no single company owns the chain – it crosses an MSA at every SI boundary, which makes constraint-store access a legal question, not an engineering one. Underneath both sits the part nobody funds: four shared stores that already half-exist in your estate. Build those first. Build implementation last.

Written for CIOs, delivery heads and tech leads at banks, insurers and NBFCs running agentic delivery across a captive team and multiple systems integrators. Use this when you are scoping an agentic SDLC programme, deciding what to build before the pilot, or renegotiating partner contracts to cover agent access. It covers intake and triage design, shared context stores, approval gates in regulated change processes, and vendor and MSA boundaries.

Anthropic put out an AI-native SDLC playbook a few weeks ago. The core idea is the good part: every stage ends by writing an artifact to version control and the next stage begins by reading it, so the chain of commits becomes the audit trail. Who asked for what, what the agent produced and who approved it.

That is a genuinely clean idea. If you work in a bank, you already know why it matters, because you have spent months of your life reconstructing exactly that chain for somebody holding a printout.

So this is not a rebuttal. It is the two things I kept writing in the margin, both of which come from doing this work in Indian BFSI, where the shape of the problem is different.

The first assumption: intent arrives clean

The playbook starts at Plan, where a person has an idea, brainstorms with Claude and produces a proto-spec saved as intent.md, which the product owner reviews and corrects before committing.

Lovely. Now go look at your actual queue.

At a lender we work with, work enters through eight different doors. Change requests from business as a paragraph in an email. Datadog firing on a p99 threshold. Jira tickets that say “not working” with a screenshot attached. ServiceNow escalations that started as a customer complaint and got translated twice on the way up from L1. Product asks sized by somebody who has never opened the repo. A partner ringing to say their integration broke. Sixty items from the last VAPT sorted by CVSS. And a Confluence page from a retro nine months ago that everyone agrees is important.

Eight formats. Eight ideas of what urgent means. Eight different stakeholders and only one of them is a product owner sitting down to write an intent.md.

Somebody is already translating all of that. Usually a tech lead or BA, in his head, between calls. One of them showed me a spreadsheet he’d been keeping privately for eleven months because his memory had stopped coping. Four tabs, one per source, colour coded. He was slightly embarrassed about it. He shouldn’t have been, it was the best documentation in that organisation.

That translation step has to become a stage. Not a person. In our framing it’s stage zero, sitting before Plan and it produces the same kind of committed artifact the playbook describes, just with more fields because the input is messier:

Origin and the raiser’s exact words
Classification, including where an item is genuinely two things
Impact surface: services, modules, owners, downstream consumers
Precedent from past similar work, with actuals against estimates
The constraint set that applies to these paths
Duplication check against the open backlog
Blast radius and who finds out first
Open questions, with names against them

The precedent field is the one everybody drops in a working group, because populating it means querying delivery history nobody has cleaned. It’s also the one that fixes your estimates. Fight for it.

The second assumption: one company owns the chain

This is the bigger one for anyone reading this in Mumbai.

The playbook’s chain works beautifully inside a single engineering organisation. A private bank or an insurer does not have one. You have a captive team, two or three SIs sitting on different towers and product vendors for the core systems who will not let you touch anything.

So the commit chain has a seam in it. Several, actually. Three things follow and I have not seen any of them written down anywhere.

The artifact matters most exactly where it crosses the MSA. Handover between your captive team and a partner is where context currently evaporates and gets rebuilt in a KT call that nobody records. If you build your intake layer only inside the captive team, you have fixed the smaller half.

Sharing your constraint store is a legal question, not an engineering one. The convention and constraint store is what stops an agent, yours or a partner’s, from quietly bypassing an audit wrapper. Which means partner access. Which means an amendment, procurement and a conversation with legal that will take five months. I know it will take five months because that is where one of ours currently sits. Start it now, not after the pilot works.

Nobody has decided who owns the productivity gain ** and your contract is silent.** On T&M, agent-assisted delivery cuts billed hours, so your partner has no reason to bring it up. On fixed price it accrues to them unless you reopen the SOW. We have seen this handled sensibly with outcome-linked pricing on new work. We have also seen it stall completely because nobody wanted to be the one to reopen a contract.

_Ask your partners what their agents are reading from your repositories today. _

The thing underneath all of it

This one is a mistake we made ourselves.

We spent most of last year starting these engagements at the build stage. It’s the interesting part, it demos well and it’s what clients ring you about. It kept falling over in production and it took me embarrassingly long to work out why: the pilots were being fed hand-curated work items by a tech lead who wanted them to succeed.

Then at another client I watched six agents, built by six different squads, all doing decent work. Five of them were separately figuring out which services a change touched. One queried the CMDB, two parsed the repo directly and one just asked a model to guess from the ticket text. None of them wrote the answer anywhere the others could see it.

The agents were fine. There was nothing underneath them.

Four shared stores fix this and every one of them already half-exists in your estate. Making them queryable is most of the actual work.

The constraint store is the one that earns its keep in a regulated shop. Which write paths must be audit-logged. Which fields carry DPDP obligations. Which services sit inside payment data localisation scope. Put it in the repository, versioned with the code. Anything living outside the merge process is stale within two quarters and a stale constraint is worse than an absent one because people trust it.

Where the human signatures go

The playbook is careful about this and I agree with where it lands. Separation of duties holds because the agent that wrote the code has no way to approve it and approval comes from a human through branch protection. Their hooks-as-gates approach is the right mechanism.

My only addition is a subtraction. Most BFSI change processes carry gates that exist because something went wrong in 2019 and nobody since has had the standing to remove them. They cost calendar time and they train everybody to approve without reading, which is the opposite of a control. Four signatures survive real scrutiny. Audit yours against those four and take the rest out.

If you’re the one funding this

The first takes a fortnight to get. Ask your tech leads to log the time they spend working out what a work item actually is before it can be assigned. In teams we’ve measured it runs between a fifth and a third of the week for the two or three people carrying most of it. That is a real cost, paid out of your most expensive engineering time and it appears in no report anywhere. It is also the strongest slide you will have.

The second is audit evidence assembly. Whatever your team currently spends pulling change evidence together for an inspection, that number moves almost immediately once release verification is automated and it is the one your board will feel directly.

What you should refuse to promise is throughput per engineer. It is what you will be asked for. It moves last, it moves least reliably and committing to it in quarter one is how these programmes die in month nine.

What I don’t have a good answer to

Juniors. The work that used to teach somebody how a core system fits together, the small tickets and tracing a bug across four services at eleven at night, is exactly what a clean intake layer removes. Somebody handed a complete work item learns less than somebody who had to go and find out. Every EM I talk to has noticed. The only remedy I can think of is deliberately withholding context from people, which nobody actually does and I don’t know what it does to your bench in three years.

So, honestly

Read the playbook. It’s better than most things published on this and the artifact chain is the right spine. Then before you build any of it, go and count your doors; and go and find out who is doing the translating today. In our experience, that person exists – has a spreadsheet and hasn’t told anyone about it.

Frequently asked questions

What is an AI-native SDLC?

In short, an AI-native SDLC is a software development lifecycle where every stage ends by committing a machine-readable artifact to version control, and the next stage begins by reading it. The chain of commits becomes the audit trail: who asked for what, what the agent produced, and who approved it. It replaces linear hand-offs between roles with a loop.

Why doesn’t the AI-native SDLC playbook work as written in BFSI?

The short answer is that it rests on two assumptions that don’t hold in a bank. The first is that intent arrives clean from a product owner, when in practice work enters through eight or more channels in eight different formats. The second is that one engineering organisation owns the whole commit chain, when a private bank or insurer has a captive team, multiple systems integrators and core product vendors – so the chain has a seam at every contract boundary.

What is stage zero in an AI-native SDLC?

Stage zero is an intake and triage stage that sits before Plan. It turns messy inbound work – emails, monitoring alerts, tickets, escalations, VAPT findings – into one normalised, committed artifact. The step already exists in most estates, but as a person doing it in their head between calls rather than as a file anyone can read. Making it a stage is what makes everything downstream reliable.

What should an intake artifact contain?

Eight fields: the origin and the raiser’s exact words; classification, including where an item is genuinely two things; the impact surface across services, modules, owners and downstream consumers; precedent from past similar work with actuals against estimates; the constraint set applying to those paths; a duplication check against the open backlog; blast radius and who finds out first; and open questions with names against them.

How do you run an AI-native SDLC across multiple vendors?

In short: start with the contract, not the tooling. The artifact matters most where it crosses the MSA, so giving a partner access to your constraint store needs an amendment, procurement and legal – budget months, and start before the pilot succeeds rather than after. Separately, decide who owns the productivity gain: on time and materials it cuts your partner’s billed hours, and on fixed price it accrues to them unless you reopen the SOW.

Which human approvals should survive in an AI-native SDLC?

The short answer is four. What enters the sprint, signed by the delivery or engineering manager; the approach before any code is written, signed by the tech lead; the merge, signed by a peer reviewer; and the production release, signed by the release manager or CAB. Most other gates in a regulated change process exist because something went wrong years ago. They cost calendar time and train people to approve without reading, which is the opposite of a control.

Who should own an AI-native SDLC programme in a bank?

In most estates it sits with the CIO or delivery head, executed by the tech leads who already carry the translation work. Use this guidance when you are scoping an agentic SDLC programme, deciding what to build before a pilot, or renegotiating partner contracts to cover agent access. It applies to banks, insurers and NBFCs running delivery across a captive team and multiple systems integrators, and it covers intake and triage design, shared context stores, approval gates and MSA boundaries.

The post AI-native SDLC in a regulated, multi-vendor delivery estate appeared first on Bluetick Consultants Inc..

AI Defenders Assemble: OpenAI Daybreak Red and Blue Land on AWS Bedrock

Bluetick Consultants Inc. — Fri, 21 Aug 2026 12:25:13 +0000

Published: August 21, 2026 | Last Updated: August 21, 2026

Key Takeaway: OpenAI Daybreak Red and Blue are now available on Amazon Bedrock for eligible enterprise customers. In summary, Daybreak Blue (GPT-5.6 Sol) is purpose-built for defensive security workflows including incident response and vulnerability discovery, while Daybreak Red

(GPT-5.6 Cyber) is purpose-trained for authorized vulnerability research and exploit validation. Bottom line: Importantly, both models run with zero-operator access enforced at the chip level – OpenAI never receives your data and never used for model training.

AWS and OpenAI have officially joined forces to revolutionize enterprise cyber defense by launching OpenAI’s specialized Daybreak models on ** Amazon Bedrock **. This launch introduces two tailored access tiers: Daybreak Blue(GPT-5.6 Sol) and Daybreak Red (GPT-5.6 Cyber). Both are available to eligible customers in the US East (Ohio) region and built to accelerate threat detection, incident response, and authorized vulnerability research inside a hardware-isolated environment.

The Two Faces of Daybreak: Blue vs. Red

Standard commercial AI models often refuse legitimate dual-use security tasks due to strict safety guardrails. Daybreak addresses this directly, providing vetted defenders with calibrated intelligence tiers matched to their operational needs.

Practical Example 1: Streamlining Incident Response with Daybreak Blue

Consider a mid-sized financial enterprise facing a potential security breach. The Security Operations Center (SOC) team detects a sudden anomaly: an internal server is communicating with an unknown external IP address using an unusual, obfuscated PowerShell script.

The Workflow

Log Analysis: First, the analyst feeds the raw, obfuscated PowerShell script and the relevant endpoint telemetry logs into an automated pipeline powered by Daybreak Blue via Amazon Bedrock.
De-obfuscation & Triage: Next, utilizing GPT-5.6 Sol, the model instantly de-obfuscates the code, mapping the script’s behavior directly to the MITRE ATT&CK framework (e.g., identifying it as a Living off the Land attack technique).
Remediation Loop: Finally, Daybreak Blue drafts a localized firewall rule to block the malicious external IP, generates an AWS IAM policy amendment to restrict the compromised server’s permissions, and writes a draft incident summary for the leadership team.

Why it matters: As a result, what typically takes an incident responder hours of manual reverse engineering happens in under two minutes, stopping lateral movement before it starts.

Practical Example 2: Validating a Zero-Day Patch with Daybreak Red

Consider this: an enterprise software provider receives a private disclosure about a critical remote code execution (RCE) vulnerability in their main application. Before they can ship a patch, they must reproduce the exploit to ensure their fix actually blocks it. Standard LLMs would completely refuse to help create or validate an exploit payload.

The Workflow

Exploit Reproduction: An authorized security researcher uses Daybreak Red (GPT-5.6 Cyber). Daybreak Red features a lower refusal threshold for trusted partners. The model analyzes the raw crash dump and generates a proof-of-concept (PoC) exploit payload to confirm the vulnerability’s impact.
Code Remediation: The developers write a patch to sanitize the vulnerable input fields.
Validation Testing: Subsequently, the researcher feeds the new patch back to Daybreak Red and asks it to modify the exploit payload to try and bypass the new defenses. The model tests the code aggressively, completing the legitimate dual-use task successfully and confirming that the patch entirely neutralizes the vulnerability.

Why it matters: Notably, according to early performance benchmarks, GPT-5.6 Cyber successfully completes 95% of legitimate dual-use security tasks , compared to a mere 1.5–2% success rate from standard, heavily restricted models.

Under the Hood: AWS Enclaves and Hardware-Enforced Privacy

Deploying these models through Amazon Bedrock addresses the primary concern of enterprise security leaders: data privacy. The architecture is engineered around absolute isolation:

Zero-Operator Access: Specifically, the models run on AWS next-generation inference engines with hardware-enforced isolation at the silicon chip level via AWS Nitro Enclaves. Specifically, no human operator—not even an AWS engineer—can view your active session data.
No Training on Enterprise Data: Furthermore, your prompts, internal logs, proprietary code, and sensitive vulnerability findings stay within your private AWS environment. Moreover, data is never shared with OpenAI and OpenAI never uses it to train future models.
Zero Data Retention: Eligible enterprises can actively request a strict zero-data-retention policy for absolute operational compliance.

The Strategic Impact: Shifting from Reactive to Predictive Defense

Overall, the arrival of Daybreak on Amazon Bedrock marks a fundamental shift in how modern enterprises manage risk. By transitioning away from brittle, signature-based detection systems, organizations unlock major strategic advantages:

Eliminating the Cyber Skills Gap: Tier-1 and Tier-2 SOC analysts can use Daybreak Blue to handle complex reverse engineering and log correlation tasks, acting as a massive force multiplier for understaffed teams.
Continuous Red Teaming: Annual external audits are no longer sufficient. With Daybreak Red, internal researchers can run continuous, automated exploit simulations to evaluate real-time architectural resilience.
Drastically Reduced Blast Radii: Consequently, automating the chain from discovery to patch mitigation delivers measurable results. Enterprises can shrink their Mean Time to Remediation (MTTR) from days to single-digit minutes.

Would you like me to tailor this expanded post further? I can:

Add a technical section with actual sample prompts used for Daybreak Blue and Red.
Create a Boto3 Python code snippet showing how to invoke these models via the Bedrock API.
Generate a custom visual image prompt for your blog’s cover graphic.

Security teams can apply for enrollment in Daybreak access directly through OpenAI.

Frequently Asked Questions

What is OpenAI Daybreak and how does it differ from standard AI models?

In short, OpenAI Daybreak is a cyber defense initiative that gives vetted security professionals governed access to frontier AI models. Unlike standard commercial AI models that refuse legitimate dual-use security tasks due to strict safety guardrails, Daybreak provides calibrated access tiers – Blue for defensive workflows and Red for advanced vulnerability research – matched with strong identity verification and access controls.

What is the difference between Daybreak Blue and Daybreak Red?

Specifically, Daybreak Blue provides access to GPT-5.6 Sol with safeguards calibrated for defensive security work such as incident response, vulnerability discovery, and detection engineering. Daybreak Red provides access to GPT-5.6 Cyber, a purpose-trained cybersecurity model with a lower refusal threshold designed for authorized tasks such as exploit reproduction, red teaming, and zero-day patch validation. Daybreak Red requires a separately approved specialist path with additional verification.

How do I get access to Daybreak Red and Blue on Amazon Bedrock?

To get started, access requires enrollment in OpenAI’s Trusted Access for Cyber program. Once approved by OpenAI, you work with your AWS account team to request model access on Bedrock. The models are currently available to eligible customers in the US East (Ohio) region.

Is enterprise data safe when using Daybreak models on Amazon Bedrock?

Yes. To be clear, both models run on Bedrock’s next-generation inference engine with zero-operator access enforced at the chip level, meaning no AWS engineer or operator can view your active session data. Your prompts, internal logs, and vulnerability findings OpenAI never accesses your findings and are never used to train future models. Additionally, eligible enterprises can also request a zero-data-retention policy.

Can Daybreak Red be used to create malicious exploits?

No. Access to Daybreak Red requires passing through OpenAI’s Trusted Access for Cyber identity and trust framework, which includes identity verification, account security monitoring, approved-use restrictions, and legal attestations. Starting September 1, 2026, all individual Daybreak accounts must also adopt hardware security keys. In other words, the lower refusal threshold is specifically calibrated for authorized defensive research, not offensive use.

How does Daybreak Blue help SOC teams with incident response?

Daybreak Blue can de-obfuscate malicious scripts, map attacker behavior to the MITRE ATT&CK framework, draft firewall rules to block malicious IPs, generate IAM policy amendments, and produce incident summaries — tasks that typically take hours of manual analysis can be completed in under two minutes, acting as a force multiplier for understaffed security teams.

What performance benchmarks has GPT-5.6 Cyber demonstrated?

According to OpenAI’s early performance benchmarks, Notably, GPT-5.6 Cyber successfully completes 95% of legitimate dual-use security tasks, compared to a 1.5–2% success rate from standard heavily restricted models.

The post AI Defenders Assemble: OpenAI Daybreak Red and Blue Land on AWS Bedrock appeared first on Bluetick Consultants Inc..

The Nuances of Payment Orchestration: Apple Pay, Google Pay, and 3DS

Bluetick Consultants Inc. — Wed, 12 Aug 2026 10:38:29 +0000

Key takeaway

Payment orchestration looks simple on a slide: one API, many processors, smart routing, higher auth rates. In production, the hard parts are the methods that sit outside a plain card-not-present charge – wallets and authentication challenges. Apple Pay, Google Pay, and ** 3-D Secure (3DS) do not behave like “just another payment method” on your PSP. They change token formats, liability, UX, retry logic, and what your orchestrator is allowed to decide.**

This post covers the nuances that matter when you design or operate an orchestration layer around those three.

Who this guide is for

This guide is written for payment engineers, fintech platform teams, e-commerce architects, and engineering leaders who are building or operating a multi-processor payment orchestration layer.

It is most useful when you are designing or improving payment flows that involve Apple Pay, Google Pay, and 3-D Secure (3DS / SCA), and when you need clear answers to these decisions:

Can a failed wallet or 3DS attempt be safely retried on another processor?
When should you step-up authentication instead of hopping to a different PSP?
How should token formats, liability shift, and attempt state be modelled so routing rules do not create hard declines?

Primary use cases this guide supports:

Designing multi-PSP payment orchestration
Handling Apple Pay and Google Pay token routing
Managing 3DS / SCA authentication and retries
Reducing hard declines caused by incorrect wallet or 3DS failover logic

Industries: E-commerce, marketplaces, fintech platforms, and any business accepting cards + digital wallets under SCA or high-fraud environments.

What orchestration actually owns

A payment orchestrator sits between your checkout and one or more processors (Stripe, Adyen, Worldpay, local acquirers, etc.). Typical jobs:

Method abstraction – present cards, wallets, and local methods through one merchant integration
Routing – pick a processor by cost, auth rate, geo, MID health, or method support
Failover – soft-decline retry on another processor without asking the shopper to re-enter details
Reconciliation & reporting – normalize statuses, fees, and dispute signals
Wallets and 3DS strain every one of those jobs. The orchestrator often cannot freely re-route a completed Apple Pay cryptogram or a finished 3DS challenge the way it can re-attempt a raw PAN authorization (and even PAN retries have network and SCA limits).

Rule of thumb: treat wallets and 3DS as stateful authentication + authorization contracts, not interchangeable rails.

Apple Pay: cryptograms, domains, and processor binding

What you actually receive

Apple Pay does not give you a reusable PAN you can freely shop around. You get a payment token (DPAN / device account number style credentials) plus a cryptogram and transaction metadata. That payload is meant for a specific merchant / processor context.

Nuances for orchestration:

Processor affinity – Many setups decrypt or process the Apple Pay token at a specific PSP. If your orchestrator wants multi-PSP Apple Pay, you usually need either:

separate merchant identifiers / payment processing certificates per processor, or
a model where the orchestrator (or a vault partner) is the Apple Pay merchant and routes the resulting network token onward.

Merchant validation is not optional theater – Domain association files, merchant ID registration, and session creation (ApplePaySession) must match the environment the shopper sees. A misconfigured domain on one brand/subdomain silently kills wallet availability while cards still work – a common “orchestration looks down” false alarm.
Button UX is part of conversion – Apple requires using their button / sheet patterns. Orchestrators that invent a generic “Wallet” button and then branch to Apple Pay often fail review or confuse users. Method discovery (show Apple Pay only when ApplePaySession.canMakePayments() / active card checks pass) belongs in the client, not only in backend routing tables.
Billing / shipping contacts – Apple Pay can return contact fields your card form never collected. Orchestration and fraud stacks must accept incomplete address shapes and map them consistently so tax, shipping, and AVS do not disagree across processors.
Recurring and merchant-initiated – Apple Pay for subscriptions and MIT flows has extra constraints (and evolving network rules). Do not assume a one-time Apple Pay auth gives you the same MIT flexibility as a card-on-file network token from a processor vault.

Orchestration implication

Failover after an Apple Pay decline is often not “send the same cryptogram to processor B.” Prefer:

retry on the same processor with adjusted parameters (if soft decline), or
fall back to another method (card form / Google Pay / local APM), or
re-invoke Apple Pay for a fresh payload if the shopper is still in session

Blind cross-PSP replay of wallet payloads is a frequent source of hard declines and support tickets.

Google Pay: two token modes that look alike

Google Pay is easy to underestimate because the UI looks like one button. Under the hood, orchestration behavior splits on tokenization specification.

Gateway tokens vs. network tokens / direct

PAYMENT_GATEWAY – Google returns a token encrypted for a named PSP gateway. Your orchestrator is effectively choosing that PSP before the sheet completes. Multi-PSP orchestration means multiple gateway configs, or accepting that Google Pay is pinned per attempt.
DIRECT / network token style setups – You (or your orchestrator) decrypt with your own keys and can, in principle, route more flexibly – at the cost of PCI scope, key management, and certification burden.

Nuances:

Allowed payment methods in the request – Card networks, auth methods (PAN_ONLY vs CRYPTOGRAM_3DS), and billing address requirements change both conversion and risk. PAN_ONLY can behave closer to a card-on-file PAN (and may trigger 3DS / SCA differently than cryptogram-backed tokens).
Environment & merchant ID – Test vs production, merchant origin, and existing method requirements differ by platform (Android app, web, certain browsers). “Works on Chrome Android, missing on Safari desktop” is often configuration, not orchestration routing.
3DS interaction – Cryptogram-backed Google Pay credentials may already carry device-binding signals. Forcing a full 3DS challenge on every Google Pay auth can hurt conversion without buying proportional fraud reduction. Your orchestrator’s risk rules should distinguish wallet cryptogram auths from raw PAN entry.
Country and processor coverage – Google Pay availability and supported networks vary. Orchestration “smart routing” must filter processors by actual Google Pay support for that MID and region, not by generic card acquiring support.

Orchestration implication

Decide early whether Google Pay is:

PSP-pinned (simpler, common): orchestrator selects PSP → client requests Google Pay for that gateway → authorize on that PSP only, or
orchestrator-decrypted (flexible, heavier): orchestrator owns keys / compliance → can route the resulting credentials with clearer rules

Mixing both models without documenting the attempt state machine creates impossible retries.

Is 3DS the same as authorization?

3DS proves who the shopper is; it does not authorize the charge. Attaching the authentication result to the authorization correctly is what preserves liability shift and avoids issuer declines.

3-D Secure (especially EMV 3DS / 3DS2 ) is an authentication protocol between merchant/requestor, directory server, and issuer ACS. Orchestration teams often collapse it into “extra redirect that reduces chargebacks.” The nuances are sharper.

Frictionless vs challenge

Issuers can:

Frictionless – authenticate based on risk data with no shopper UI
Challenge – OTP, banking app, biometrics, etc.

Your orchestrator must preserve:

authentication path (transStatus values like Y / A / N / U / R / C, depending on version and mapping)
ECI / CAVV (or AVV) / dsTransID / threeDSServerTransID
version (2.1.0 vs 2.2.0 matters for data and exemptions)

Authorization without correctly attaching authentication data is how you lose liability shift and get issuer declines.

SCA, exemptions, and TRA

In regulated regions (notably PSD2 SCA in Europe), 3DS is entangled with:

Low-value exemptions
Transaction Risk Analysis (TRA)
Trusted beneficiaries (allowlisting)
MIT / recurring out-of-scope or one-leg-out cases

An orchestrator that always “does 3DS” or never does can both be wrong. Optimal policy is usually:

Risk engine proposes challenge / frictionless / exemption
Processor / 3DS server executes
Auth result feeds authorization
Soft declines like “soft decline – authenticate” (soft decline / 1Z style issuer guidance, processor-specific codes) trigger a step-up , not a blind processor hop

Cross-processor 3DS

This is the sharp edge of orchestration:

A 3DS authentication completed with Processor A’s 3DS server is generally not portable to Processor B’s authorization.
Re-routing after challenge completion usually means re-authenticating , which means more friction and possible shopper drop-off.
Some vault / network token strategies reduce pain for retries, but they do not magically make ACS results universal.

Design for attempt-scoped authentication: bind attempt_id → processor → 3DS result → auth. Failover rules should know whether a new 3DS is required.

Data quality decides frictionless rates

3DS2 expects a rich browser and, where applicable, app SDK data (accept headers, viewport, IP, device channels, etc.). Orchestrators that proxy checkout through multiple frontends or WebViews often strip fields and accidentally force challenges. Measure challenge rate and frictionless rate per channel, not only overall auth rate.

How the three collide in one checkout

Real checkouts combine these paths:

Liability shift is not binary marketing copy

Liability shift depends on method, region, network, authentication result, and merchant category. Apple Pay / Google Pay cryptogram transactions and successful 3DS can each shift liability under conditions – but fraud tools, friendlier fraud, and certain MCCs still leave residual risk. Orchestration reporting should separate:

authenticated vs not
wallet vs PAN
challenged vs frictionless
exemption claimed vs authenticated

Otherwise finance and risk argue from different truths.

Practical design principles for orchestrators

Model payment method as a state machine , not a string enum. States like WalletSessionCreated, TokenReceived, ThreeDSMethodUrl, Challenged, Authenticated, Authorized, SoftDeclinedNeedsStepUp prevent illegal transitions (e.g., “route elsewhere after challenge”).
Separate method eligibility from processor routing. Eligibility: can this shopper use Apple Pay here? Routing: which MID should take this attempt? Google Pay gateway selection often is routing.
Prefer step-up over hop when the decline reason is authentication-related. Prefer hop when the decline is acquirer/MID health related and you still have routable credentials.
Normalize decline taxonomy across PSPs – especially soft decline / SCA required / do not honor / lost-stolen. Raw processor codes are not an orchestration policy.
Keep client SDKs honest. Apple Pay and Google Pay need client-side capability checks; 3DS needs correct browser data and challenge windows (including iframes, pop-ups, and native SDK UI). Backend-only orchestration cannot fix a broken challenge UX.
Test the ugly paths: challenge cancel, challenge timeout, Apple Pay sheet dismiss, Google Pay STATUS_CANCELED, partial address, and “auth success / authz fail.” Those dominate real abandonment more than happy-path auth rates.

What “good” looks like

Teams that handle these nuances well usually share outcomes:

Wallet and 3DS attempts are attempt-scoped with clear processor binding
Retries are reason-aware (step-up vs re-route vs new wallet sheet)
Risk policy treats cryptogram wallets differently from typed PANs
Product analytics track sheet open → authorized funnels separately from card forms
Compliance and domain/merchant setup are monitored like uptime, not like one-time onboarding

Payment orchestration creates leverage only when it respects the contracts of the methods it routes. Apple Pay, Google Pay, and 3DS are not edge cases — they are where conversion, liability, and authorization integrity are won or lost.

Frequently Asked Questions

Do Apple Pay and Google Pay work across multiple payment processors?

No, not freely. Apple Pay and Google Pay credentials are generally bound to the merchant and processor context in which they are requested. An Apple Pay cryptogram or a PAYMENT_GATEWAY-encrypted Google Pay token is typically intended for a specific PSP.

Supporting multiple processors usually requires separate merchant IDs, certificates, or gateway configurations for each processor. Alternatively, an orchestrator or vault partner can hold the wallet-merchant role and route the resulting network token onward.

Because wallet credentials are not interchangeable like raw card details, replaying a completed Apple Pay or Google Pay payload against another processor can result in a hard decline. Payment orchestration should therefore treat wallet attempts as processor-aware and attempt-scoped.

Does Google Pay always require 3DS?

No, Google Pay does not always require 3DS. The requirement depends on the authentication method carried by the Google Pay token, the transaction’s risk profile, and applicable SCA requirements.

A CRYPTOGRAM_3DS token is device-bound and already carries 3-D Secure authentication signals. Forcing an additional full 3DS challenge in every case can add unnecessary friction and reduce conversion without providing proportional fraud protection.

A PAN_ONLY token behaves more like a stored card credential and may require 3DS or SCA separately. The payment orchestrator should therefore distinguish between CRYPTOGRAM_3DS and PAN_ONLY rather than applying the same 3DS policy to every Google Pay transaction.

Why does a payment retry succeed on one processor but fail on another after 3DS?

Because a completed 3DS authentication is generally tied to the processor and 3DS server that performed the authentication. The authentication result cannot always be transferred directly to another processor’s authorization request.

For example, if Processor A performs the 3DS challenge and the authorization subsequently fails, sending the same authenticated transaction directly to Processor B may fail because Processor B cannot necessarily use Processor A’s authentication result.

Re-routing after a completed challenge may therefore require a fresh authentication, which introduces additional friction and potential shopper drop-off.

The safer approach is to use attempt-scoped payment orchestration: bind the attempt_id to the processor, 3DS result, and authorization together. Failover rules should understand whether the transaction can be retried directly or requires a new authentication step.

Does using a digital wallet or 3DS guarantee chargeback protection?

No, using a digital wallet or 3DS does not guarantee chargeback protection. Liability shift depends on the payment method, region, card network, authentication result, and merchant category.

Cryptogram-backed Apple Pay and Google Pay transactions, as well as successfully authenticated 3DS transactions, can provide liability-shift benefits when the applicable conditions are met. However, liability shift is not automatic and does not eliminate all dispute or fraud exposure.

Friendly fraud, certain merchant category codes, authentication outcomes, and network-specific rules can still result in merchant liability.

For accurate risk reporting, payment orchestration systems should distinguish between:

Authenticated vs. unauthenticated transactions
Wallet vs. PAN payments
Challenged vs. frictionless 3DS
Exemption-based vs. authenticated transactions

This gives risk and finance teams a consistent view of authentication, authorization, and dispute exposure.

Need an architecture review of your wallet & 3DS orchestration?

Most teams discover gaps only after hard declines or failed Apple Pay domain validation.

Book a focused architecture review of your current routing, retry, and authentication state machine.

→ Book Architecture Review

→ Contact Us

The post The Nuances of Payment Orchestration: Apple Pay, Google Pay, and 3DS appeared first on Bluetick Consultants Inc..

Postgres 19 Learned to Speak Graph

Bluetick Consultants Inc. — Fri, 07 Aug 2026 00:00:44 +0000

SQL/PGQ, and why your relational database was a graph all along

In short: PostgreSQL 19 ships SQL/PGQ, letting you query your existing relational tables as a graph – no new database, no data migration. It’s built for backend engineers and DBAs currently writing multi-join queries for fraud detection, permissions, recommendations, or hierarchy traversal. It supports fixed-depth pattern matching today; variable-length paths aren’t supported yet.

Who this is for: Backend engineers, DBAs, and data architects running PostgreSQL who currently write multi-join or recursive-CTE queries to model relationships. Use this when you’re building fraud detection, permission audits, recommendation queries, or hierarchy traversal, and want to know whether SQL/PGQ can replace those queries or an entire second graph database.

I have spent 7 years moving data between systems. One pattern repeats more than any other.

A team hits a slow query. They buy a specialised database to fix it. Three years later they are maintaining a pipeline instead of building features.

Graph databases are the classic case. Someone needs to find “customers who share a device with a customer who charged back.” They write a recursive CTE. It takes 90 seconds. By the end of the quarter there is a Neo4j cluster, a Kafka topic, a schema drift problem, and a new on-call rotation. All to answer a question about data that never left Postgres.

PostgreSQL 19 changes this. Beta 1 landed on June 4, 2026, and it ships SQL/PGQ : SQL Property Graph Queries, standardised as ISO/IEC 9075-16:2023.

SQL/PGQ lets you declare a graph over tables you already have. Then you query it with graph syntax. No new storage engine. No extension. No ETL. No second copy of your data.

It is a bigger deal than the release notes suggest. It also does less than the hype suggests. This post covers both halves.

1. What actually shipped

The core idea is simple: a property graph is a view .

You are not creating an object that stores anything. You write DDL that says which of your tables are nodes, which are edges, and how they connect. Postgres saves that in the catalog.

Here is the important part. When you run a graph query, the rewriter turns your pattern into ordinary joins. This happens before the planner ever sees it.

So everything you already have keeps working:

Your indexes work
Your table statistics work
EXPLAIN works
Parallel query works
Row-level security works

In other words, it is the same machinery. You just get a new front door.

Declaring a graph

A graph has two parts. Vertex tables are your nodes. Edge tables are the connections between them.

CREATE PROPERTY GRAPH social_graph
  VERTEX TABLES (
    users LABEL person
      PROPERTIES (id, name, email, joined_at),
    posts LABEL post
      PROPERTIES (id, title, created_at)
  )
  EDGE TABLES (
    follows
      SOURCE KEY (follower_id) REFERENCES users (id)
      DESTINATION KEY (followed_id) REFERENCES users (id)
      LABEL follows
      PROPERTIES (created_at),
    likes
      SOURCE KEY (user_id) REFERENCES users (id)
      DESTINATION KEY (post_id) REFERENCES posts (id)
      LABEL liked
      PROPERTIES (created_at)
  );

That is the long form. If your tables already have primary keys and foreign keys, Postgres works most of it out for you:

CREATE PROPERTY GRAPH myshop
  VERTEX TABLES (products, customers, orders)
  EDGE TABLES (
    order_items SOURCE orders DESTINATION products,
    customer_orders SOURCE customers DESTINATION orders
  );

Six lines. A working graph over an existing schema. Zero data moved.

How to read the syntax

The arrows look strange at first. They are simpler than they appear.

(a IS person) -[IS follows]-> (b IS person)
    └────┬────┘ └─────┬────┘ └────┬────┘
       a node an edge a node

Four rules cover almost everything:

So the pattern above reads: a person a , who follows, a person b .

Two more things to know.

The word before IS is an alias. You only need it if you want to use that element later:

-[f IS follows]-> named f, so you can read f.created_at in COLUMNS
-[IS follows]-> no name, you just want to filter by the label
-[f]-> any edge at all, named f

IS matches the label, not the table name. In the example above the table is called follows and its label is also follows. That is only because Postgres uses the table name as the default label. If you had written LABEL knows, the pattern would be -[IS knows]-> even though the table is still follows.

Querying it

Graph queries go inside GRAPH_TABLE:

SELECT * FROM GRAPH_TABLE (social_graph
  MATCH (a IS person WHERE a.name = 'Alice')
        -[f IS follows]->(b IS person)
  COLUMNS (b.name AS followed_name)
);

GRAPH_TABLE takes three things: a graph name, a MATCH pattern, and a COLUMNS list. It returns a normal relation.

That last point matters a lot. Because the result is a normal relation, plain SQL wraps around it:

SELECT followed_name, count(*) AS follower_count
FROM GRAPH_TABLE (social_graph
  MATCH (a IS person)-[IS follows]->(b IS person)
  COLUMNS (b.name AS followed_name)
)
GROUP BY followed_name
HAVING count(*) > 1
ORDER BY follower_count DESC;

Aggregates, window functions, CTEs, joins against non-graph tables. All of it works. This is the single biggest advantage over a bolt-on graph database, and I come back to it later.

The full pattern grammar

That is the whole language. You can learn it in an afternoon.

Managing graphs

ALTER PROPERTY GRAPH social_graph ADD EDGE TABLE ...;
DROP PROPERTY GRAPH social_graph; does NOT touch your tables

In psql, \dG lists your graphs. The catalog tables are pg_propgraph_element, pg_propgraph_label, pg_propgraph_property and pg_propgraph_label_property.

2. Why graphs matter at all

Here is the thing nobody says plainly. Relational databases are good at graphs. They are bad at expressing graphs.

Take a three-hop question. “Which products were bought by customers who share a payment card with a customer who filed a chargeback?”

In SQL that is six joins. Three of them are self-joins on the same table with different aliases. You will spend twenty minutes checking that c1, c2 and c3 are on the right side of each condition.

As a result, the query ends up correct-ish and unreadable. The next person to touch it rewrites it from scratch, because reading it is harder than rewriting it.

By contrast, the graph version is one line that looks like the sentence you said out loud.

Above all, that is the real benefit, and it is a human one. Graph syntax shortens the distance between the question and the query. When your fraud analyst can read the query, the query gets reviewed. When it gets reviewed, it gets fixed.

There is a second reason, and this one is technical. It is about join depth.

Every hop in a relational traversal is a fresh index lookup. That is O(log n) into a B-tree, plus a heap fetch, plus whatever the planner decided about join order.

Native graph engines work differently. They use index-free adjacency: each node physically stores pointers to its neighbours. So each hop is O(degree). A pointer chase, not a search.

On a billion-edge graph, ten hops deep, that gap is not 2x. It is closer to three orders of magnitude.

Remember that number. It is the honest boundary of what PG19 can do, and section 5 comes back to it.

Where graph shapes show up

Almost everywhere, once you start looking:

Fraud and AML. Shared devices, addresses, cards, IPs. Ring detection is a cycle query.
Identity resolution. Merging customer records across systems is connected-component finding.
Permissions. User to group to role to permission to resource is four hops. You probably run it on every request.
Supply chain. A bill of materials is a graph, full stop.
Recommendations. “Customers who bought X also bought Y” is a two-hop traversal.
Org and franchise hierarchies. Reporting lines, multi-location networks, ownership chains.
Data lineage. Which dashboards break if I drop this column?
GraphRAG. Retrieval over an entity graph instead of a vector blob. A lot of serious RAG work has moved this way.

Notice how many of these you are already doing. You do them with recursive CTEs and hand-written join chains. You have a graph workload. You just called it “the reporting query.”

3. Why Postgres, and why now

Three things came together.

The standard finally exists

SQL/PGQ became part of ISO SQL in 2023.

Before that, “graph query language” meant one of three things. Cypher, from Neo4j. Gremlin, from Apache. PGQL, from Oracle. Three dialects, no portability, and an obvious lock-in problem. Most enterprise architects would not sign off on it.

A standard changes procurement, not just syntax.

Postgres keeps absorbing other databases

The last five years have been a slow retreat from using a different database for every job. Look at what Postgres has taken over:

Therefore, graph was the missing piece.

Every one of those wins happened for the same reason. One copy of the data. One transaction boundary. One backup. One security model. Correctness beats specialisation for the common case, and the common case is most of the market.

AI made relationships load-bearing

Vector search finds things that are similar. It cannot find things that are connected.

GraphRAG, agent memory, entity resolution over LLM-extracted facts. All of it needs traversal. Until now, all of it needed a second database.

And one less flattering reason

Apache AGE split the ecosystem, and nobody was happy about it.

AGE gives you Cypher on Postgres. But it is an extension with its own storage, its own catalog, limited mixing with plain SQL, and a support matrix that lags behind core releases. It works. It just never felt like Postgres.

In contrast, core SQL/PGQ does feel like Postgres, because it is not a bolt-on. It is the rewriter.

How it got built

Peter Eisentraut posted the first prototype in February 2024. His own word for it was “fragile.”

Ashutosh Bapat added WHERE inside patterns and fixed the memory bugs. Others added cyclic patterns, permissions, RLS support, collation rules, LABELS() and PROPERTY_NAMES(), multi-pattern matching and ECPG support.

Two years. Around 15,000 lines across a hundred-plus files. And a deliberate choice to ship a small correct subset first.

That is the process you want behind a feature you are going to run a fraud system on.

4. A practical example

The most useful graph pattern in production is not a deep traversal. It is the shared neighbour.

Two things are not connected to each other. But both point at the same third thing.

Once you can see that shape, you find it everywhere. Two accounts on one device. Two customers on one card. Two products in one basket. Two people in one group.

Here it is on the most generic schema possible. Some entities, the groups they belong to, and a junction table joining them.

Tables you already have. Nothing about them changes.

CREATE TABLE people (id bigserial PRIMARY KEY, name text, email text);
CREATE TABLE organizations (id bigserial PRIMARY KEY, name text);

A junction table. This is an edge, and you didn't know it.
CREATE TABLE memberships (
  person_id bigint REFERENCES people(id),
  org_id bigint REFERENCES organizations(id),
  role text,
  joined_at timestamptz,
  PRIMARY KEY (person_id, org_id)
);

Now the graph. This is the whole migration:

CREATE PROPERTY GRAPH network
  VERTEX TABLES (
    people LABEL person PROPERTIES (id, name, email),
    organizations LABEL organization PROPERTIES (id, name)
  )
  EDGE TABLES (
    memberships
      SOURCE people DESTINATION organizations
      LABEL belongs_to PROPERTIES (role, joined_at)
  );

Zero rows written. Zero downtime. Reversible with one DROP.

The question: who else belongs to an organization that Alice belongs to?

Before

This is the query you would write today:

SELECT DISTINCT p2.id, p2.name
FROM people p1
JOIN memberships m1 ON m1.person_id = p1.id
JOIN memberships m2 ON m2.org_id = m1.org_id
JOIN people p2 ON p2.id = m2.person_id
WHERE p1.name = 'Alice'
  AND p2.id <> p1.id;

Four joins. Two of them are self-joins on the same table with different aliases.

It is correct. It is also the kind of query where swapping m1.org_id and m2.person_id gives you something that still runs, still returns rows, and is quietly wrong.

After

SELECT DISTINCT peer_id, peer_name
FROM GRAPH_TABLE (network
  MATCH (a IS person WHERE a.name = 'Alice')
        -[IS belongs_to]->(o IS organization)
        <-[IS belongs_to]-(peer IS person)
  COLUMNS (peer.id AS peer_id, peer.name AS peer_name)
);

In fact, same plan. Same indexes. Same runtime.

What changed is that you can now see the answer in the shape of the text. Two arrows meeting at one o. Alice goes out to an organization. Someone else comes back in from it.

You can check that line for correctness by looking at it. You cannot do that with the four-alias version.

It composes

GRAPH_TABLE returns an ordinary relation, so plain SQL wraps straight around it:

SELECT peer_name, count(*) AS shared_orgs
FROM GRAPH_TABLE (network
  MATCH (a IS person WHERE a.name = 'Alice')
        -[IS belongs_to]->(o IS organization)
        <-[IS belongs_to]-(peer IS person) COLUMNS (peer.name AS peer_name) ) GROUP BY peer_name HAVING count(*) > 1
ORDER BY shared_orgs DESC;

That reads: “people who share more than one organization with Alice, most overlap first.”

A dedicated graph database does not give you that for free. You would pull the rows back to your application and count them there. Here it is a GROUP BY.

The same query, five products

Swap the nouns. The pattern does not change.

That is why the syntax is worth learning. Not for any one query. For the fact that the query stops being domain plumbing and starts being a shape you recognise.

5. The limitations. Read this before you plan anything.

PG19’s implementation is deliberately conservative. What is missing is not an oversight. It is a community choosing to ship a correct subset rather than a shaky superset.

But you need to know exactly where the wall is.

Not supported in PostgreSQL 19

Variable-length paths. You cannot write “one or more hops” or “between two and five hops.”
Quantified patterns. No *, + or {m,n} after an edge.
Open-ended traversal. No “all paths from A to B, any length.”
Shortest path.
Transitive closure.
Security-definer graphs. Invoker semantics only.
Graph-native indexes. There is no adjacency structure. Only your B-trees.

Of these, the first one is the one that matters.

Everything in PG19 is fixed depth. If you cannot write the number of hops as a literal number in the query, PG19 cannot express it.

Legal in PG19. Exactly two hops, spelled out.
MATCH (a IS person)-[IS belongs_to]->(o)<-[IS belongs_to]-(b IS person) NOT legal in PG19. "Two to five hops." MATCH (a IS person)-[IS belongs_to]->{2,5}(b IS person)

The workaround

Recursive CTEs still work, and you should keep them. Given any self-referencing table, say org_units (id, name, parent_id):

Full ancestry chain, unknown depth. Still the right tool in PG19.
WITH RECURSIVE chain AS (
  SELECT id, name, parent_id, 1 AS depth
  FROM org_units WHERE name = 'Northwest Branch'
  UNION ALL
  SELECT u.id, u.name, u.parent_id, chain.depth + 1
  FROM org_units u JOIN chain ON u.id = chain.parent_id
  WHERE chain.depth < 20 always bound your recursion
)
SELECT * FROM chain;

The honest performance note

The rewriter produces N joins for an N-hop pattern.

On the other hand, for two or three hops over indexed foreign keys, Postgres is genuinely competitive with a dedicated graph database. It always was. We just could not say it nicely before.

However, for deep, unbounded traversal over a large graph, index-free adjacency still wins. No amount of query rewriting closes that gap.

So do not let the excitement talk you out of Neo4j if you are doing ten-hop pathfinding on a billion edges. That is a real workload, and SQL/PGQ is not the answer to it.

6. Converting your relational database to a graph

This is the part people actually need.

The good news: you are not converting anything. There is no data migration. What you are doing is modelling. You are deciding which of your tables are nouns and which are verbs.

The decision procedure

Walk your schema. Put every table into one of four buckets.

Bucket A: entity tables become vertex tables

A table is a vertex if a row is a thing that exists on its own. Customers, products, orders, devices, accounts, users, locations.

The test: could a business person point at a row and name it? Then it is a vertex.

Bucket B: pure junction tables become edge tables

These have a composite primary key of exactly two foreign keys and no identity of their own. Things like order_items, customer_devices, user_roles, post_tags.

They map to edges with no ceremony at all:

EDGE TABLES ( order_items SOURCE orders DESTINATION products LABEL contains )

If the junction table carries extra columns, expose them as edge properties. Edges having properties is the whole reason it is called a property graph.

Bucket C: entity tables with inline foreign keys become both

In practice, this is where most schemas live. It is also where most people get stuck.

orders.customer_id is a relationship. But there is no junction table to point at.

The trick: list the table a second time under an alias. Use the foreign key as the source and its own primary key as the destination.

EDGE TABLES (
  orders AS placed
    SOURCE KEY (customer_id) REFERENCES customers (id)
    DESTINATION KEY (id) REFERENCES orders (id)
    LABEL placed
)

Now orders is a vertex, because it is a thing with an id and a total and a status. It is also the source of a placed edge from customer to order. Same rows, two roles.

Likewise, a table with three foreign keys becomes three aliased edges.

Bucket D: leave it out

Audit logs. schema_migrations. Denormalised reporting tables. Event streams. Soft-delete tombstones. Translation tables.

A property graph is a lens, not a mirror. Every table you add is noise in every pattern you write.

Model the 20% of your schema that carries the questions you care about.

You can define several small graphs instead of one 200-table monster. A fraud_graph, a catalog_graph, an authz_graph. You absolutely should.

The awkward cases

Self-referencing foreign keys like parent_id, manager_id, replied_to_id. These are Bucket C. Source and destination are both the same table:

ALTER PROPERTY GRAPH network
  ADD EDGE TABLE org_units AS reports_to
    SOURCE KEY (id) REFERENCES org_units (id)
    DESTINATION KEY (parent_id) REFERENCES org_units (id)
    LABEL reports_to;

This is the highest-value conversion in most schemas. It is exactly where your recursive CTEs live.

Polymorphic associations like commentable_type and commentable_id. Hello, Rails.

SQL/PGQ needs a real foreign key target. So split the polymorphic table into one edge definition per concrete type, filtered by a view. Or normalise into explicit join tables.

Admittedly, this is the one place conversion costs you real work. It is also the one place where the graph model is telling you something true about your schema.

Composite keys are supported:

SOURCE KEY (tenant_id, customer_id) REFERENCES customers (tenant_id, id)

This matters for multi-tenant systems. Do not drop the tenant column out of the key, or you will traverse across tenants.

Missing foreign key constraints are common in schemas that grew fast.

You can declare SOURCE KEY ... REFERENCES ... in the graph where no real constraint exists. Do not do it. Add the real constraints first.

Graph traversal over unenforced referential integrity will find paths through corrupt data and report them as fact. A fraud alert generated from a dangling foreign key is worse than no alert at all.

Multiple labels per table are allowed. You can model staff as both person and employee.

Tables that share a label must expose matching properties: same names, same types. Use this for genuine polymorphism. Do not use it to be clever.

A conversion checklist

Pick one question, not a schema. “Detect device-sharing fraud rings” beats “graph-ify the database.” A graph built for one question is small, reviewable, and shippable this week.
Add the missing foreign key constraints for the tables in scope. Use NOT VALID then VALIDATE CONSTRAINT if the tables are large and busy.
Index every source and destination key. The rewriter produces joins, and joins want indexes. Junction tables usually need the reverse index too. If (order_id, product_id) is the primary key, you probably also need (product_id, order_id). Traversal goes both ways.
Classify your tables into A, B, C and D. Write it down before you write any DDL. The modelling argument is the actual work.
Write the ** CREATE PROPERTY GRAPH.** It is catalog-only DDL. It takes milliseconds and touches no rows.
Port one query. Keep the original. Diff the results with EXCEPT in both directions. Both should return zero rows.
Run EXPLAIN (ANALYZE, BUFFERS) on both. The plans should be nearly identical. If the graph version is worse, it is almost always a missing index on a traversal key.
Then expand, one question at a time.

Importantly, every step is reversible. DROP PROPERTY GRAPH removes a catalog entry and nothing else.

This is the lowest-risk “migration” I have ever recommended. It barely deserves the word.

Why you should do it

Readability compounds. Traversal queries rot fastest. They get copy-pasted, mis-aliased, and never refactored. Making them legible is a lasting maintenance win.
You get to delete a system. If you run a graph database only for two and three hop questions, you can probably retire it. Along with its CDC pipeline, its lag, and its separate permission model.
One transaction boundary. Your graph result is consistent with the write that just committed. No replication lag between “the order was placed” and “the fraud graph knows about it.” For fraud and permissions, that is correctness, not convenience.
One security model. RLS applies. Roles apply. Your auditor does not have to learn a second permission system.
It is a standard. Portable to other engines that implement ISO/IEC 9075-16. Oracle already does.
Trying it costs almost nothing. Declaring a property graph cannot make your existing SQL slower. It adds a catalog entry and a syntax option.

Why you might not

Your traversals are genuinely deep and variable-length. Wait for the feature, or keep the specialised engine.
You need shortest path, PageRank, community detection or centrality. SQL/PGQ is a query language, not a graph analytics library.
You are on PG 18 or older and cannot upgrade this year.
Your team writes three traversal queries a year. Then join syntax is fine, and this is a solution looking for a problem.

7. Pros and cons

Pros

Cons

Versus the alternatives

Overall, the pattern is clear. SQL/PGQ wins on integration and loses on depth.

In short, pick accordingly. And notice that most production “graph” workloads are two or three hops.

8. Verdict

SQL/PGQ in PostgreSQL 19 is not a graph database. It is something more useful to more people.

It is an honest admission that your relational schema was already a graph, plus the syntax to say so.

The limitation everyone will complain about, no variable-length paths, is real and will be fixed. What ships today is the 80% case: bounded traversals over indexed foreign keys, written in a way a human can review.

If you run a fraud check, a permissions check, a recommendation query or a hierarchy walk, you can adopt this in an afternoon. Keep every index you have. Delete nothing but complexity.

And the migration story is the best part, because there is not one. You write six lines of DDL against a catalog and your database has a graph in it. If you do not like it, you drop it.

Seven years of watching teams buy a second database to answer a question about data in their first one. The fix turned out to be a view. That is usually how it goes.

Frequently Asked Questions

Is PostgreSQL 19 a graph database?

No. SQL/PGQ defines a property graph as a read-only view over your existing

relational tables. There is no graph storage engine, no adjacency structure, and

no data duplication – graph patterns are rewritten into ordinary joins before the

planner ever sees them.

Do I need to migrate data to use SQL/PGQ?

No. CREATE PROPERTY GRAPH is catalog-only DDL. It writes zero rows,

takes milliseconds, and DROP PROPERTY GRAPH removes the catalog entry

without touching your tables.

Does SQL/PGQ support variable-length paths?

Not in PostgreSQL 19. Every pattern is fixed depth – you cannot write quantifiers

like *, + or {2,5} after an edge. Shortest

path and transitive closure are also unsupported. Recursive CTEs remain the right

tool for unbounded traversal.

SQL/PGQ or Apache AGE – which should I use?

SQL/PGQ is built into core, uses ISO standard syntax, and composes with ordinary

SQL including aggregates and window functions. Apache AGE is an extension with its

own storage and Cypher syntax, but it does support variable-length paths. Choose AGE

if you need unbounded traversal today; choose SQL/PGQ for bounded traversals you want

readable and transactionally consistent.

When is PostgreSQL 19 released?

Beta 1 was announced on 4 June 2026 and Beta 2 on 16 July 2026. General

availability is scheduled for late 2026. Don’t run SQL/PGQ in production until the

final release.

Start here. Pick your worst multi-hop join query. Write it as a GRAPH_TABLE pattern. Show it to someone who does not write SQL. If they can read it, you have your business case.

The post Postgres 19 Learned to Speak Graph appeared first on Bluetick Consultants Inc..

From “Tokenmaxxing” to Real ROI: How to Move Agentic AI Beyond Engineering

Bluetick Consultants Inc. — Fri, 31 Jul 2026 00:00:03 +0000

Key takeaway: 95% of enterprise generative-AI pilots fail to show measurable ROI. Uber closed that gap with “Agentic Pods” – engineer-and-domain-expert pairs on a 10-day sprint – running 16 pods across 16 business functions in two months, with results like a 15-hour finance workflow cut to 30 minutes. This playbook is for CTOs, ops leaders, and finance/HR/support heads who want AI to survive contact with real workflows, not just a pilot deck.

Most enterprises are buying copilot seats and hoping for magic. The companies pulling ahead are doing something harder and far more valuable: rebuilding their actual workflows around AI agents. Here is a practical playbook, plus a detailed look at how Uber put it into practice.

Why Do Most Enterprise AI Pilots Fail?

Most companies approach corporate AI the same way. They buy thousands of generic copilot seats, roll them out across the org, and wait for the productivity curve to bend. A few months later the picture is familiar: a large monthly software bill, marginal gains, and employees who mostly use AI to rewrite their emails.

The data backs up the disappointment. MIT’s research on enterprise AI found that roughly 95% of corporate generative-AI pilots produced no measurable business impact. The models are not the weak link. Instead, the problem is that off-the-shelf copilots are built for isolated task completion, while real corporate work is messy, manual, spread across a dozen legacy systems, and almost never documented the way it actually happens. A copilot can help you write a paragraph. It cannot run the seven-system, approval-heavy process your finance team grinds through every Monday.

Piping every task through an external model API and calling it a strategy has a nickname among engineers: “tokenmaxxing.” It looks like progress on a dashboard. but it rarely shows up in the P&L.

The Real Bottleneck Is Deployment, Not the Model

The AI industry has reached the same conclusion, and it is spending billions to fix it. Between May and July 2026, four of the biggest names in AI (Anthropic, OpenAI, AWS, and Microsoft) committed roughly 9 billion dollars combined to a single idea: embedding their own engineers directly inside customer organizations to make AI work in production. For example, AWS alone put 1 billion dollars into a Forward Deployed Engineering unit that drops pods of five or six engineers into a customer to build systems in their own environment. Microsoft announced a 2.5 billion dollar division for the same purpose. Job postings for these “forward deployed engineers” have climbed roughly 800% in a year.

The common thread is simple: a great model is not a great outcome. Someone has to sit inside the building, learn how the work really gets done, and build the thing that turns a raw capability into a result. You do not have to hire an outside vendor to do this. The most effective version of the model is to build it in-house.

The Playbook: Agentic Pods

The core structure is a lean, cross-functional squad, call it an Agentic Pod. Each pod pairs one AI-proficient engineer, someone who already understands your internal systems and data, one-to-one with a domain expert from an operational function like finance, HR, or support. No consultants drawing high-level roadmaps. No off-the-shelf tool the business team is left to adopt on its own. Just a builder and a doer, side by side, redesigning one workflow at a time.

Two rules make it work. First, use internal engineers, because they already know your APIs, microservices, and data structures, which lets them integrate an agent natively instead of bolting one on. Second, put them next to the people doing the manual labour. That’s because real shortcuts, compliance nuances, and software friction only become visible from the inside.

How Does the 10-Day Sprint Framework Work?

Give every pod a hard two-week deadline and a repeatable cycle. The deadline is not incidental. It forces the team to ship something real instead of polishing something perfect.

Days 1-2, Shadow. The engineer sits beside the domain expert, watches every click, tracks the handoffs between systems, and documents the unwritten habits that never make it into a manual.

Day 3, Prioritize. The pair ranks opportunities by scale, repetition, business impact, and whether the underlying data is actually available.

Days 4-5, Build. Engineer and expert build a working agent together, so it fits the real tools and steps rather than an idealized version of them.

Days 6-9, Validate. The agent is tested against several other people doing the same job, to confirm it generalizes across the team and genuinely improves the work.

Day 10, Ship. The agent goes straight into the production workflow.

Three Principles for Enterprise AI That Works

The workflow is the unit of automation. The biggest gains rarely come from automating a single task, like drafting an email. They come from redesigning an entire multi-step workflow around an agent. When an agent owns a process end to end, it naturally removes unnecessary approvals, unifies scattered vendor tools, and cuts legacy friction that no one previously had the authority to fix.
Solve the agent identity problem early. More autonomy means more scrutiny of what agents are allowed to do. Before an agent acts on behalf of an employee, your identity and access stack has to be ready for it. Role-based access control, query validation, and clear data attribution are what keep auditing, compliance, and security intact once the agent is the one taking the action.
Build with your workers, not for them. You cannot design an elite agentic system from the outside looking in. The real friction points only surface when a builder sits next to the person doing the job every day. That is exactly why the sprint starts with two full days of shadowing before anyone writes a line of code.

A Detailed Example: How Uber Put This Into Practice

The clearest real-world proof of this model comes from Uber.

From Engineering to Every Business Function

Uber first saturated AI inside its own engineering org. By CTO Praveen Neppalli Naga’s account, 99% of Uber engineers now use AI tools, more than 70% of pull requests are attributed to local or cloud agents, and engineers have built over 2,500 agent skills across the software development lifecycle. That success raised a sharper question: if AI had already transformed how Uber builds software, what would it take to transform finance, legal, marketing, support, HR, and procurement?

In response, Uber’s answer was Agentic Pods. It handpicked around 30 of its most AI-proficient engineers and paired each with a domain expert from a business function, giving every pod exactly two weeks and the ten-day sprint described above. As Naga put it, you have to understand how the work actually gets done, because process diagrams never capture the copy-paste steps and informal approvals that make up the real thing.

The Results: 16 Pods and Uber’s Finch Finance Agent

In two months, Uber ran 16 Agentic Pods across 16 different business functions. The reported time savings:

Business function	Operational task	Before	After
Finance and Treasury	Capital allocation modeling across 150 global cities	15 hours	30 minutes
Corporate Finance	Financial pacing and budget runway reports	2 days	10 minutes
Marketing Operations	Localized web quality assurance	2 weeks	50 minutes
Customer Support	Building complex routing and support logic	9,000 manual workflows	Self-service automation

Take one agent in detail. “Finch” now lives inside Slack for Uber’s finance teams. Instead of writing SQL across multiple platforms, an analyst asks a plain-English question like “What was gross bookings in the US and Canada last quarter?” and gets a governed, permission-checked answer in seconds. Under the hood, Finch uses a supervisor agent that routes each question to specialist sub-agents, orchestration built on LangGraph, and role-based access control that enforces who can see what. A simplified version of that routing logic looks like this:

from langgraph.graph import StateGraph, END
from typing import TypedDict

class FinchState(TypedDict):
    question: str
    user_role: str
    route: str
    answer: str

# Role-based access control runs before any data is touched
def check_access(state: FinchState) -> FinchState:
    allowed = {
        "analyst": ["bookings", "pacing"],
        "admin": ["bookings", "pacing", "payroll"],
    }
    topic = classify_topic(state["question"])
    if topic not in allowed.get(state["user_role"], []):
        state["answer"] = "Access denied for this data domain."
        state["route"] = "end"
    else:
        state["route"] = topic
    return state

# Supervisor routes each question to the right specialist sub-agent
def supervisor(state: FinchState) -> str:
    return state["route"]

def bookings_agent(state: FinchState) -> FinchState:
    state["answer"] = run_governed_query("gross_bookings", state["question"])
    return state

def pacing_agent(state: FinchState) -> FinchState:
    state["answer"] = run_governed_query("budget_pacing", state["question"])
    return state

graph = StateGraph(FinchState)
graph.add_node("access", check_access)
graph.add_node("bookings", bookings_agent)
graph.add_node("pacing", pacing_agent)
graph.set_entry_point("access")
graph.add_conditional_edges(
    "access",
    supervisor,
    {"bookings": "bookings", "pacing": "pacing", "end": END},
)
graph.add_edge("bookings", END)
graph.add_edge("pacing", END)

finch = graph.compile()

result = finch.invoke({
    "question": "What was gross bookings in the US and Canada last quarter?",
    "user_role": "analyst",
})
print(result["answer"])

Large result sets export automatically to a linked spreadsheet. Speed never comes at the cost of security or auditability.

What surprised Uber most was not the speed. It was how quickly engineers dropped into unfamiliar departments started spotting problems that insiders had stopped noticing, opportunities that were, in Naga’s words, hiding in plain sight. Uber is now forming a dedicated team to scale the approach and go deeper, treating workflow redesign as a permanent discipline rather than a one-time experiment.

A Word on ROI

However, none of this justifies itself automatically. Uber’s own leadership has been candid that heavy AI investment has not yet produced a proportional wave of new consumer features, and that the cost deserves close scrutiny. Set against MIT’s 95% pilot-failure figure, the lesson is clear. The workflow-first model earns its keep precisely because it ties AI spend to specific, measurable tasks: hours saved on a named report, weeks compressed on a real QA cycle, rather than to a seat count and a hope. If you cannot point to the workflow and the hours it gave back, you are probably still tokenmaxxing.

Frequently Asked Questions

What is an Agentic Pod?

An Agentic Pod pairs one AI-proficient engineer with one domain expert from a business function like finance or HR, on a fixed 10-day sprint to build and ship a working AI agent for a real workflow.

Why do most enterprise AI pilots fail?

MIT’s research found 95% of corporate generative-AI pilots show no measurable business impact, mainly because generic copilots aren’t built for the messy, multi-system workflows that make up real corporate work.

How is an Agentic Pod different from a typical AI pilot or consultant engagement?

A typical pilot hands the business a generic tool and hopes it fits. An Agentic Pod embeds an internal engineer directly with the person doing the job for two days of shadowing before any code is written, so the agent is built around the real, undocumented workflow rather than an idealized version of it.

How do I start an Agentic Pod without Uber’s resources?

You don’t need 30 engineers or a dedicated team. One AI-fluent engineer, one willing domain expert, a hard two-week deadline, and a single high-friction workflow with existing data is enough to run a first pod and measure the hours it returns.

Getting Started

You do not need Uber’s scale to copy this. The ingredients are modest: a few AI-fluent engineers, willing domain experts, a hard deadline, and a rule that you observe the work before you automate it. Start with one or two high-friction workflows where the data already exists, run a single two-week pod, and measure the hours it returns.

The most profitable AI opportunities in your company are probably not sitting in a vendor’s product roadmap. They are hiding in your messiest, most manual, everyday operations. You just have to send your best builders onto the floor to find them.

The post From “Tokenmaxxing” to Real ROI: How to Move Agentic AI Beyond Engineering appeared first on Bluetick Consultants Inc..

Microsoft Foundry vs Amazon Bedrock in 2026: The Model Is No Longer the Decision

Bluetick Consultants Inc. — Fri, 24 Jul 2026 11:57:42 +0000

For two years, enterprise AI platform selection had a shortcut. If you needed GPT, you went to Azure. If you needed Claude, you went to AWS. The model catalog made the decision, and the architecture followed.

However, that shortcut is gone.

In June 2026, OpenAI revised its exclusive cloud arrangement with Microsoft, and GPT-5.5, GPT-5.4, and Codex reached general availability on Amazon Bedrock. Weeks later, Anthropic’s Claude models reached general availability in Microsoft Foundry, hosted on Azure. Both frontier families now run on both platforms. The era of choosing a cloud to reach a lab is effectively over.

This comparison breaks down Microsoft Foundry vs Amazon Bedrock across governance, agent runtime, and cost – the factors that actually decide your platform choice in 2026.

As a result, this creates an uncomfortable situation for engineering leaders who built their platform strategy on model access. The decision did not disappear. It moved. It now sits in the agent runtime, the governance boundary, and the question of whose legal entity processes your data.

Quick answer: Both Claude and GPT now run on Bedrock and Foundry, so model access isn’t the deciding factor anymore. The real differences are in agent runtime, data residency/trust boundary, and cost structure – not which model you can access.

A naming note before we start

Azure AI Studio became Azure AI Foundry in late 2024. Foundry was then rebranded again to Microsoft Foundry. Most practitioners still say “Azure AI Foundry,” Microsoft’s own documentation is inconsistent, and search results for the platform span three names.

This is a small thing, but it is a real signal. Microsoft’s AI surface has changed names and shapes faster than teams can update their internal architecture documents, and that churn has a cost. We will return to it.

Model breadth: a metric that stopped mattering

The catalog comparison is still worth stating, if only to retire it.

Microsoft Foundry lists well over 1,900 models in its own documentation, spanning OpenAI, Anthropic, Meta, Mistral, DeepSeek, xAI, Cohere, NVIDIA, and a deep Hugging Face integration. Counts above 10,000 appear in some third-party write-ups, depending on how open-weight variants are tallied.

Amazon Bedrock is deliberately narrower: roughly 18 providers and somewhere north of 110 individually addressable model variants as of mid-2026, including Amazon’s own Nova family, Anthropic’s Claude line, Meta Llama, Mistral, Cohere, and now OpenAI.

Here is why that gap matters less than it looks. In practice, nobody evaluates 1,900 models. Teams evaluate three or four, pick one, and then spend eighteen months operating it. A catalog is a procurement convenience, not an engineering advantage. The 1,900 versus 110 comparison flatters Microsoft in a slide deck and tells you almost nothing about what you will actually run in production.

What does matter: both platforms now carry the frontier models most enterprises shortlist. Claude Fable 5, Anthropic’s most capable widely released model, has been generally available on Amazon Bedrock, Google Cloud, and Microsoft Foundry since June 9, 2026, alongside Claude Opus 4.8, Sonnet 5, and Haiku 4.5. Foundry carries that line next to the GPT-5.x family. Bedrock carries the same Claude line next to GPT-5.5 and GPT-5.4. Pricing on Bedrock for OpenAI models matches OpenAI’s direct rates and draws down existing AWS commitments. Claude usage in Foundry bills through Azure Marketplace and draws down Microsoft Azure Consumption Commitments.

In short, model access has become table stakes. Commercial plumbing is now the differentiator, and both vendors know it.

Is Claude Available on Both Microsoft Foundry and Amazon Bedrock?

Yes. Anthropic’s Claude models – including Claude Fable 5, Opus 4.8, Sonnet 5, and Haiku 4.5 – are generally available on both Amazon Bedrock and Microsoft Foundry as of mid-2026, alongside Google Cloud. The difference between the two platforms is no longer which models you can access, but how that access is delivered: Claude on Bedrock runs inside your own AWS tenant, while Claude on Foundry is delivered through Anthropic as a third-party marketplace processor.

Agent Runtime: Where AWS and Microsoft Really Differ

The biggest difference between AWS and Microsoft is now their agent runtime, and many comparison articles are already outdated.

Amazon Bedrock has shifted from the original Bedrock Agents to AgentCore, which is now the recommended platform. AgentCore is modular and framework-agnostic, offering services like Runtime, Gateway, Memory, Identity, and Observability. It works with popular frameworks such as LangGraph, CrewAI, LlamaIndex, and the OpenAI Agents SDK, while also providing a managed runtime, built-in web search, and integrated guardrails.

Microsoft has also unified its ecosystem with Microsoft Agent Framework 1.0, replacing both AutoGen and Semantic Kernel as the primary development framework. Combined with Foundry Agent Service, it delivers managed hosting, durable execution, MCP support, and enterprise observability.

Ultimately, the main trade-off is simplicity. AWS offers a more streamlined path from framework to managed runtime, while Microsoft’s ecosystem is more feature-rich but spread across multiple products such as Agent Framework, Foundry, Copilot Studio, Microsoft 365 Agents SDK, and Agent 365, making the learning and adoption curve steeper.

Grounding and retrieval

Key Takeaway:

The biggest differentiator is where your enterprise data already resides , not the retrieval technology itself. If your knowledge is in AWS services , Bedrock is the natural choice. If it lives in Microsoft 365 and Azure , Foundry provides deeper native integration.

Governance & Compliance: Key Differences

Both platforms are enterprise-ready with strong security, compliance, and governance capabilities.
Amazon Bedrock
- Supports ISO, SOC, GDPR, FedRAMP High, and is HIPAA eligible.
- Bedrock Guardrails provide content filtering and policy enforcement independent of the underlying model.
- Includes automated reasoning capabilities to improve response reliability.
Microsoft Foundry
- Inherits Azure’s enterprise security stack, including Entra ID, RBAC, Managed Identities, Private Endpoints, CMKs, and data residency controls.
- Ideal for organizations already invested in the Microsoft ecosystem.

Important Consideration: Model Trust Boundary

Azure OpenAI models run entirely within Microsoft’s Azure trust boundary.
Claude on Microsoft Foundry is delivered through Anthropic, making Anthropic the data processor.
Claude on Amazon Bedrock runs within your AWS environment, helping meet stricter data residency and compliance requirements.

Bottom Line

Choose Bedrock if data residency and regulatory compliance (especially in Europe) are critical.
Choose Foundry if you’re primarily using Azure OpenAI models and are already standardized on Azure.
Always verify the latest documentation, as cloud AI offerings and compliance capabilities evolve rapidly.

Cost: where the money actually goes

Notably, both platforms are pay-as-you-go and both track their model providers’ direct API pricing within a narrow band. Per-token rate shopping between them is rarely worth the effort.

Three things move the number instead.

Data gravity and egress.

If your applications run on Lambda or ECS and you call Bedrock, transit costs stay at zero. Hosting data in S3 while routing inference through Foundry introduces network egress fees and latency on every call. This integration tax compounds silently and is usually discovered after the architecture is set.

Routing and optimization Building blocks.

Foundry’s Model Router deploys as a single endpoint and selects the underlying model per prompt, with modes optimized for balanced performance, cost, or quality. Bedrock counters with Intelligent Prompt Routing, prompt caching, and Model Distillation, where AWS reports distilled models running substantially faster and cheaper with limited accuracy loss. Both sets of building blocks are real and both are underused. Most teams leave meaningful savings on the table by calling one frontier model for every request, including the trivial ones.

The self-hosting tipping point.

There is a threshold at which migrating high-volume, low-complexity work, such as classification, extraction, and routine summarization, onto a fine-tuned open-weight model on dedicated compute beats managed per-token pricing. Where that threshold sits depends on your token mix, latency tolerance, and the fully loaded cost of the engineers who will operate the inference stack. Be suspicious of any article that names a specific request-per-day number. Model your own workload. The managed-versus-self-hosted crossover has moved every year, and the operational cost of self-hosting is chronically understated.

Worth noting: agent runtimes now bill separately from inference. Foundry Agent Service charges consumption on compute and memory, with model inference and persistent memory billed on top. Budget for the runtime as its own line item.

Which Should You Choose: Microsoft Foundry or Amazon Bedrock?

First, retire the model-availability question. It no longer separates these platforms.

At a glance, here is how the two platforms line up across the dimensions that actually decide it:

Dimension	Microsoft Foundry	Amazon Bedrock
Model catalog	1,900+ models listed, with a deep Hugging Face integration	Roughly 18 providers and 110+ model variants, deliberately curated
Frontier models	GPT-5.x family alongside the Claude line (Fable 5, Opus 4.8, Sonnet 5, Haiku 4.5)	Claude line alongside GPT-5.5 and GPT-5.4, plus Amazon Nova
Agent runtime	Microsoft Agent Framework 1.0 (AutoGen and Semantic Kernel merged); Foundry Agent Service for managed hosting	AgentCore: composable and framework-agnostic, with a managed harness that needs no orchestration code
Grounding and retrieval	Foundry IQ over MCP; native reach into SharePoint, Teams, Graph, Fabric, and Azure SQL	Fully Managed Knowledge Bases via AgentCore Gateway; native S3, Confluence, and Salesforce
Governance and trust boundary	Azure compliance stack and Entra ID; OpenAI is first-party, Claude is a third-party marketplace offering with no EU data zone today	ISO, SOC, FedRAMP High, and HIPAA eligible; Claude inference runs in your own tenant with documented residency
Cost drivers	Pay-as-you-go; Claude billed through Azure Marketplace and MACC; Model Router for per-prompt selection	Pay-as-you-go; draws down AWS commitments; Intelligent Prompt Routing and distillation
Best fit	Microsoft-centric shops on M365, Entra ID, and SharePoint with Azure-approved compliance	AWS-native teams valuing composability, or anyone needing Claude in-tenant with residency, especially regulated EU

Ask these instead, in order.

Where does your data live, and what will it cost to move? This is the highest-signal question and it usually answers the others. Cross-cloud inference carries a permanent tax.
Which trust boundary does your legal team need? Not which platform, which boundary. First-party inference and third-party marketplace inference are different things wearing the same badge. If you are in a regulated European industry and Claude is central to your architecture, this question likely eliminates Foundry today.
How much orchestration control do you want, and how much churn can you absorb? Bedrock and AgentCore give you a composable, framework-agnostic runtime and a cleaner path from prototype to production. Microsoft gives you a richer integrated ecosystem, deeper Microsoft 365 reach, and a wider set of surfaces to keep track of. Both vendors just forced a migration on their existing agent customers. Assume they will do it again.
What is your team’s existing operational muscle? Foundry rewards Microsoft shops with Entra ID, Fabric, and SharePoint already in production. Bedrock rewards teams fluent in IAM, CloudTrail, VPC endpoints, and the AWS building-block style.

Therefore, if you are Microsoft-centric, run Microsoft 365 and Entra ID, want evaluation, observability, and agent monitoring in one console, and your compliance posture is already Azure-approved, Foundry is the path of least resistance.

A concrete example of where that plays out:

A national insurer building an internal underwriting assistant. Its policy documents, underwriting guidelines, and claims correspondence already live in SharePoint and Teams, identity runs through Entra ID, and its compliance team approved Azure years ago. It wants an agent that answers underwriter questions from that corpus and logs every interaction for audit. Foundry IQ reaches SharePoint and Microsoft Graph natively, Agent 365 gives governance the audit surface it needs, and legal has no new trust boundary to review. The knowledge never leaves the environment it already lives in, which is exactly why the project ships in a quarter instead of a year.

If you are AWS-native, value composability over integration, want a framework-agnostic agent runtime, or need Claude inference running inside your own tenant with documented residency guarantees, Bedrock is the stronger fit.

A concrete example of where that is the clear call:

A European digital bank building customer operations on Claude. It needs documented data residency and inference that runs inside its own cloud tenant, and its regulators will not accept a third-party marketplace processor subject to the CLOUD Act. That single constraint decides it. Claude through Bedrock keeps inference in-tenant with residency guarantees the bank’s legal team can point to, and Foundry, today, cannot offer the Claude equivalent. Here the governance section outranks everything else, exactly as warned.

And if your honest answer is “we are already both,” you are not unusual. The multi-cloud reality is why model gateways and MCP-based abstraction layers went from a nice-to-have to a design pattern in the space of about a year. Build the abstraction before you need it, not after your provider announces the next rename. Not sure which platform fits your architecture? Get a free AI Opportunity Audit.

That abstraction is smaller than it sounds. A thin provider interface lets your application target either cloud, so switching Claude between Bedrock and Foundry, or moving a workload entirely, becomes a configuration change rather than a rewrite:

# A thin provider interface: swap clouds without touching application code
from dataclasses import dataclass

@dataclass
class ModelRequest:
    prompt: str
    system: str
    max_tokens: int = 1024

class ModelProvider:
    def invoke(self, request: ModelRequest) -> str:
        raise NotImplementedError

class BedrockProvider(ModelProvider):
    # Claude inference stays inside your own AWS tenant
    def invoke(self, request: ModelRequest) -> str:
        return bedrock_runtime.converse("anthropic.claude-fable-5", request)

class FoundryProvider(ModelProvider):
    # Billed through Azure Marketplace against your MACC
    def invoke(self, request: ModelRequest) -> str:
        return foundry_client.responses("gpt-5-5", request)

def answer(question: str, provider: ModelProvider) -> str:
    request = ModelRequest(
        prompt=question,
        system="You are an internal knowledge assistant. Cite your sources.",
    )
    return provider.invoke(request)

# Switching providers is a one-line change, not a re-architecture
gateway = BedrockProvider()
print(answer("Summarize this quarter's underwriting exceptions.", gateway))

This same discipline of writing precise, portable specs instead of one-off prompts is why spec engineering is becoming a core skill for AI teams.

FAQ: Microsoft Foundry vs Amazon Bedrock

Which platform is better for regulated industries like banking or healthcare?

It depends on which trust boundary your compliance team requires. Amazon Bedrock runs Claude inference inside your own AWS tenant with documented data residency, which tends to satisfy stricter regulatory requirements, especially in the EU. Microsoft Foundry delivers Claude through Anthropic as a third-party marketplace processor, which may not meet the same residency bar today.

Can I use both Microsoft Foundry and Amazon Bedrock at the same time?

Yes, and many enterprises already do. A common pattern is running Foundry for internal Microsoft 365-integrated tools while using Bedrock for AWS-native or Claude-in-tenant workloads. A thin provider-agnostic abstraction layer (see the code example above) makes switching between the two a configuration change rather than a rewrite.

Does switching agent runtimes require rebuilding my agents from scratch?

Not necessarily, but expect some migration work. AWS moved from Bedrock Agents to AgentCore, and Microsoft merged AutoGen and Semantic Kernel into Agent Framework 1.0 – both vendors have already forced at least one runtime migration on existing customers, so building with framework-agnostic tooling (like LangGraph or CrewAI) reduces future lock-in.

Is Microsoft Foundry the same as Azure AI Foundry?

Yes. Azure AI Studio was rebranded to Azure AI Foundry in late 2024, then renamed again to Microsoft Foundry. Most documentation and practitioners still use “Azure AI Foundry” interchangeably, so don’t assume they’re different products if you see both names.

Which platform has lower costs?

Per-token pricing is similar on both platforms since they track each model provider’s direct API rates. The bigger cost differences come from data egress fees (if your data and inference are on different clouds), agent runtime billing (which is now separate from model inference on both platforms), and whether you eventually migrate high-volume, low-complexity workloads to self-hosted open-weight models.

Platform capabilities, model availability, and residency terms in this space change on a monthly cadence. Every claim here reflects publicly available documentation and reporting as of July 2026 and should be verified against vendor documentation before an architectural commitment is made.

The post Microsoft Foundry vs Amazon Bedrock in 2026: The Model Is No Longer the Decision appeared first on Bluetick Consultants Inc..

Claude Tag: Bringing an AI Teammate Into Your Workspace

Bluetick Consultants Inc. — Fri, 17 Jul 2026 00:00:07 +0000

How tagging @claude in Slack turns AI from a tool you visit into a colleague that pulls its weight

Most AI tools sit and wait. You open a tab, type a prompt, copy the answer back into your real work, and close it again. Claude Tag turns that model inside out. Instead of you going to the AI, the AI comes to where your team already works, and it starts pulling its weight like any other member of the team.

Here’s what Claude Tag is, why it matters, how your team can put it to work, where it’s heading, and the mistakes to steer clear of along the way.

What is Claude Tag?

Claude Tag is a new way for teams to work with Claude, and it starts in Slack. Rather than living in a separate app, Claude joins your workspace as a team member. An administrator grants it access to the channels, tools, data, and even codebases you choose, and from then on anyone in a channel can simply tag @claude and hand off a task.

When you tag Claude with a request in plain language, it breaks the work into stages and works through them using the tools it has access to. Then it replies in the thread with what it produced: a drafted document, a data analysis, a merged pull request, or a step toward resolving an incident.

You can reach Claude through three surfaces:

Channel tagging: tag @claude in a channel and the whole team can follow along as it works in the thread.
Direct messages: start a private conversation for work you’d rather keep out of a shared channel.
AI assistant panel: open Claude from anywhere in Slack using the assistant icon.

Built on Claude Opus 4.8

Claude Tag is the next generation of Claude Code, made more proactive and built to work with a full team rather than a single person. It runs on Claude Opus 4.8, acts under its own identity, remembers the relevant context from the channels it’s in, and can follow up on its own. Anthropic reports that it has become one of the main ways its own teams get work done. In fact, 65% of its product team’s code now comes from an internal version. That pattern has spread beyond engineering, too, into chasing down product metrics, working through support tickets, and tracking tricky bugs. Slack’s leadership has described the change as making AI “multiplayer”: instead of a private back and forth in a DM, your assistant shows up in the open where the team already works.

If your organization already uses the Claude in Slack app, Claude Tag is a transition rather than a fresh install. It runs under the same Slack app, your existing setup keeps working, and administrators have a 30 day window to opt in. The older experience switches over to Claude Tag on August 3, 2026, so the move comes with a deadline attached. Eligible Team and Enterprise organizations also get an introductory launch credit so they can trial it.

What are the benefits?

What makes Claude Tag different from a normal chatbot is simple: it behaves more like a colleague than a tool. A few qualities stand out:

It’s multiplayer. Within a channel there’s a single Claude that everyone shares. Because the whole exchange stays visible, a teammate can steer it mid-task or pick up exactly where someone else left off.
It learns over time. As Claude follows a channel, it builds context about the work, so people don’t have to re-explain the basics on every request. With permission, it can also draw on knowledge from other channels and connected sources.
It takes initiative. Turn on ambient behavior and Claude stops waiting to be asked. It flags relevant information from across its channels and tools, and follows up on threads or tasks that have gone quiet without being resolved.
It works asynchronously. Hand it a task and get on with your day. Claude can schedule work for itself and pursue a project over hours or days, which means a team can delegate to many Claudes running in parallel.
It’s governable. Administrators decide exactly which tools and data each channel’s Claude can reach, set hard spending limits for the organization and for individual channels, and review an audit log of every action and who requested it.

Putting Claude Tag to work day to day

The clearest way to understand Claude Tag is to picture it living in the channels your team already uses. A few examples:

HR operations. Drop Claude into an #hr-help channel connected to your policy documents and HR systems. Employees can ask about leave balances, benefits, or expense rules and get an instant, consistent answer instead of waiting on the HR team. Behind the scenes, Claude can draft job descriptions, summarize themes from exit-interview notes, or flag requisitions that have been sitting without approval. Because it remembers the channel’s context, the HR team isn’t re-explaining policy every week.

Onboarding. A new hire’s first days are full of small, repetitive questions. In an #onboarding channel, Claude can welcome each joiner, point them to the right setup guides and accounts, and answer the endless “where do I find this?” questions. With ambient behavior on, it can also nudge a manager when a checklist item has stalled or a first-week task is still incomplete. The new hire gets help on demand, and the people who would normally field those questions get their time back.

Beyond HR. The same pattern extends across the company. A support team can tag Claude to triage incoming tickets, a product team can ask it to chase down metrics, an engineering channel can have it investigate the root cause of a tricky bug or open a pull request, and a sales team can have it follow up on quiet deals. Each lives in its own channel with its own scoped access, so the sales Claude never touches engineering’s data and vice versa.

In every case the payoff is the same: routine, context-heavy work gets handled right where it happens, which frees your people to focus on the judgment calls that actually need them.

How this shapes the future of work

Claude Tag points to a real shift in how teams and AI work together. Three changes stand out.

First, the default interaction is flipping from “open an app and prompt” to “delegate to a teammate who’s already here.” When AI lives in the flow of work, using it stops being a separate task.

Second, work becomes parallel. If one person can hand off several tasks to several Claude’s at once and check back later, the bottleneck shifts. It moves from doing the work to directing and reviewing it. Orchestrating and quality-checking AI teammates becomes a core professional skill.

Third, institutional knowledge stops living only in people’s heads. A Claude that remembers a channel’s history becomes a kind of durable, shared memory: context that survives when individuals are busy, on leave, or move on.

The Battle for the Workplace

There’s a commercial story here too. Tools that behave like a “virtual employee” living inside a workspace are quickly becoming the battleground for enterprise AI, and Claude Tag is Anthropic’s bid to own that entry point in Slack before rivals do. For buyers, the real takeaway isn’t about any single vendor. It’s about a change in what “using AI at work” even means, from a tool that individuals open to shared infrastructure a whole organization plans around.

Anthropic has said it plans to bring Claude Tag well beyond Slack over time. If it gets there, an AI teammate that’s present, proactive, and accountable across every place a team works won’t feel like a product feature anymore. It’ll just be how work gets done.

Steps to avoid when using Claude Tag

A proactive AI in your workspace is powerful precisely because it has access and initiative, and that’s exactly why a few habits matter. Avoid these:

Granting access too broadly. Scope each channel’s tools, data, and repositories to what that work actually needs. Use private channels to keep sensitive connections (legal, finance, HR) separate from everything else.
Skipping spend limits. Claude Tag is consumption-based, so set an organization-wide cap and per-channel limits before a wide rollout, and watch the alerts that fire at 75% and 95% of a limit.
Putting sensitive material in the wrong place. Memory is scoped to the channel, so be deliberate about where confidential conversations happen, and remember Claude won’t report out from private channels.
Skipping governance. Review what Claude remembers, check the audit log of tasks and actions, and remember that only a Primary Owner or Owner should configure its access, not every admin.
Letting it act on untrusted input. Claude reads the conversation around it and can follow instructions buried in those messages, so keep it to trusted channels and be deliberate about what external or unvetted content it can see.
Treating its output as final. Claude drafts, analyzes, and proposes; a person should still review pull requests, data, and decisions before they ship.
Confusing the billing surfaces. Tagging Claude in a channel is billed to the organization under its shared identity, while direct messages run on your personal Claude account. Worth knowing before people lean on one or the other.

Used well, Claude Tag isn’t a chatbot you visit. It’s a teammate you trust with the routine, so your people can spend their time where it actually counts.

The post Claude Tag: Bringing an AI Teammate Into Your Workspace appeared first on Bluetick Consultants Inc..

AI Governance: Innovation, Risk Management, and Boardroom Accountability

Bluetick Consultants Inc. — Mon, 30 Jun 2025 13:13:45 +0000

The Boardroom Wake-Up Call
Picture it's 2 AM, and your phone is buzzing with urgent messages. Your company's AI system just made a decision that could either save millions or trigger a regulatory nightmare. As you sit up in bed, one terrifying thought crosses your mind: "Do I even know how to evaluate whether this AI system is helping or hurting us?"
Everyone’s talking about artificial general intelligence, gen AI, AI agents, automation... The board is excited. And you’re probably already managing a few AI-powered tools or features across your org.
But here’s what almost no one’s saying out loud:
We’ve built the engine. We’re building the rocket. But no one’s talking about the control panel.
That’s what AI governance is. And in 2025, it’s exactly what will separate those who scale AI confidently and those who end up in cleanup mode when something goes wrong.

What is AI governance
If the board asked, “How much risk is being run with our current AI use and what are those risks?” could the impact, dependencies, and safeguards behind each AI system be clearly explained? A strong governance model is how those answers are delivered confidently.
AI governance isn’t a document or a dashboard. It’s the entire system that ensures your AI works the way it’s supposed to even when you’re not in the room.
AI governance is the framework of policies, processes, and accountability measures that ensure AI systems are used safely, ethically, and effectively within an organization. It covers decision rights, risk management, compliance, and oversight across the AI lifecycle.
According to McKinsey's March 2025 study, AI governance led by the CEO or board of directors correlates with stronger AI return on investment (ROI). Specifically, 28% of companies report that their CEO is responsible for AI governance, while 17% say the board of directors leads on AI governance.
That’s why leading firms tie governance directly to budget owners and tech execs.

What’s really at stake for your team, your board, and your company
You’re rolling out artificial intelligence, from AI automation in ops to experimenting with gen AI for customer service. But when you think of AI, I want you to think two steps ahead and ask yourself:
Could this go sideways and who’s watching?

When the board asks ‘show me the guardrails,’ what do I say?

Why it matters right now and what happens if you don’t act
If your company is already using some form of artificial intelligence whether that’s intelligent automation, predictive analytics, or generative AI tools embedded in your SaaS stack, then here’s the real problem: AI adoption has outpaced AI accountability.
And when things go wrong with AI, they go wrong fast and publicly without leaving time to fix it quietly behind the scenes.
Let me paint three real, simple scenarios:
An internal HR chatbot gives biased hiring suggestions and you don’t find out until someone files a complaint.

A generative AI tool generates customer-facing content that accidentally violates compliance language.

An AI model used in underwriting quietly updates itself after a few months of drift, and approval rates change with no one noticing until your CFO flags anomalies in quarterly revenue.

None of these sound like sci-fi. They sound like tomorrow morning's email.
Without AI governance, you don’t just risk technical debt, you risk legal exposure, reputational loss, and customer trust. And, that’s why approximately 47% of companies reported AI governance as one of their top five strategic priorities.

AI Governance Framework: What it looks like in practice
This isn’t about creating bureaucracy. This is about having a system that supports growth without exposing you to blind spots. Here’s what that actually means:
Clarity on what’s ‘AI’ in your company
Don’t assume everyone’s on the same page. Is gen AI in a CRM email builder considered AI? What about Excel plugins? Start by mapping what tools are in play and who owns them.

Defined ownership and sign-off
Who decides if a new AI use case is approved? Is there a review process? Do you have criteria for high-risk vs low-risk AI? This isn’t just about compliance, it's about control.

Auditability and explainability
If your board committee asks, “Why did our AI say no to that loan?” can you answer? Can you show inputs, outputs, and who touched the model last?

Human-in-the-loop systems
Not every AI decision should be fully autonomous. For anything sensitive, hiring, finance, legal build in human checkpoints, just like you'd review a contract before signing it.

Incident response before you need it
If your AI misfires, who does what? Who pulls the plug? Who talks to legal, PR, or compliance? You don’t want to write this plan after the mistake.

Frequently Asked Questions on AI Governance

What is AI governance?

AI governance is the set of policies, processes, and oversight mechanisms that ensure artificial intelligence systems are developed, deployed, and managed responsibly. It covers areas such as accountability, risk management, compliance, data ethics, and transparency helping organizations align AI use with business goals, legal requirements, and stakeholder trust.

What are the key components of an effective AI governance framework?
A strong AI governance framework includes clear policies on data usage, model accountability, risk assessment, compliance (like GDPR/CCPA), and oversight roles. It ensures AI initiatives align with both business goals and ethical standards.
How can we ensure our AI models are compliant with regulations and internal policies?
Start by implementing audit trails, bias monitoring, and explainability protocols. Partnering with legal and compliance teams early helps reduce regulatory risk and builds trust across the organization.
What are the best practices for setting up an AI ethics board or governance committee?
Include cross-functional leaders from IT, legal, risk, and product teams. Define clear roles, review cycles, escalation paths, and set measurable KPIs to track responsible AI deployment.
How do we balance innovation speed with governance controls in AI development?
Use a tiered approach to apply stricter governance to high-risk use cases (like healthcare or finance) while allowing more flexibility in lower-risk experimentation. Automating parts of the governance workflow also helps accelerate delivery.
What tools or platforms can help us operationalize AI governance at scale?
Look for platforms that offer model monitoring, bias detection, version control, and explainability dashboards. Many organizations integrate these with existing MLOps pipelines or use third-party tools built for enterprise AI oversight.

Final Word: What I’d Tell You If We Were in the Same Room
Most companies right now are moving forward with AI and hoping it all just works out.
They’re waiting for clearer regulations, vendor checklists, or someone to tell them, “This is how it’s done.”
But there’s no one-size-fits-all for AI governance, where guidance is still catching up to the pace of deployment.
That’s exactly why this is your leadership moment. If you're in charge of technology and you’re responsible for how AI gets built or scaled in your company then governance is not someone else’s job. It’s yours.
When you take the time to build a governance model that fits your business, your risk appetite, and your culture,then you’re not slowing things down. You’re making sure they can actually scale. Safely. Accountably. Without the mess.
Companies that treat AI governance as a foundation not an afterthought are already moving faster, earning more trust, and keeping regulators, investors, and customers on their side. And if you're not sure where to begin, that's okay. Most aren’t.

Bluetick Consultants Inc.: Your Partner in Responsible, Scalable AI Integration
At Bluetick, we don’t just build AI solutions, we work with leadership teams to build the operational trust layer that keeps innovation on course. Our AI practice combines deep technical knowledge with real-world understanding of enterprise governance, data privacy, and risk mitigation.
Whether you're piloting your first generative AI tool or managing dozens of AI-powered workflows, we help you design governance systems that fit your org chart, not someone else's template, implement explainability, auditability, and human oversight in real environments and align technology with board-level accountability and regulatory readiness

Our goal is simple: help you scale AI without creating messes you’ll have to clean up later. You can move fast and get it right.

Looking to integrate AI into your business the right way? Speak with our AI team. We will help you design, govern, and scale AI securely and strategically.

How to Build a Website That Grows Your Business

Bluetick Consultants Inc. — Wed, 18 Jun 2025 13:41:03 +0000

Introduction

Whether you're launching a new product, offering services, or trying to build authority in your space, your website plays a direct role in how fast (or slow) your business grows. It's not just about how it looks; it’s about how it performs.

Fast load times, airtight security, mobile responsiveness, and seamless user experience, these are no longer ‘nice to haves’. They’re what Google, and more importantly, your customers, expect. And if your current site falls short, you’re leaving money on the table, plain and simple.

In this guide, I’ll walk you through the technical essentials, and a step-by-step guide to building a results-driven website that performs from day one.

Clarify Business Goals & Understand Your Audience

Start by defining the primary objectives for your website. Drive bookings? Increase online sales? Build trust in your brand? The answer will shape every decision moving forward, from design to development to user experience.

Define KPIs That Matter

Think in terms of measurable outcomes. What does success look like? Some common KPIs to track for websites that grow businesses include: number of product or service bookings, conversion rates (newsletter signups, purchases, contact form submissions), engagement metrics (time on site, bounce rate) and brand visibility.

Know Your Audience (Better Than Your Competitors Do)

Not everyone visiting your site is ready to buy — some are just browsing, some are comparing options, and a few are ready to convert.
Here’s how you can get into their heads:

Create user personas: Map out your typical customers — their roles, needs, goals, challenges, and the language they use.
Define your core conversion paths: What are the top actions you want users to take? Whether it’s scheduling a demo, requesting a quote, or downloading a brochure, your site needs to guide them toward that action seamlessly.
Collect real input: Talk to your sales team, support team, or even your customers to understand what information they look for on your site.

Align Features With Your Goals

Make sure you have a fast, mobile-optimized booking system, smart forms, and CRM integration. Every feature you add should serve a purpose.

2. Choose the Right Platform & Setup

Your choice of platform and technical setup lays the foundation for everything else — speed, SEO, security, scalability, and how easy it is to maintain or expand.

Why WordPress is a Smart Choice

If you want flexibility, scalability, and full control over your site, go with WordPress. WordPress powers 43.4% of the web worldwide for a reason. Whether you're running a small business or scaling to serve enterprise-level traffic, WordPress grows with you. You get access to thousands of plugins, themes, and developer-friendly tools that help you

Managed Hosting

Here’s what you should look for in your hosting setup: Free SSL Certificate (for security), Fast Load Speeds (with built-in caching and CDN support), and Daily Automated Backups (to restore your site with a single click)

Server-Side Features

While you might not interact with these features daily, they play a big role in performance and security: HTTP/2 Support (Ensures faster page load times by sending multiple requests in parallel), Compression (like GZIP or Brotli) (reduces the file size) and Automatic Security Patches (keeps server and CMS up to date and protected from the latest threats).

When you get the platform and infrastructure right, your site becomes faster, safer, and easier to grow.

3. Prioritize UX: Mobile, Speed & Navigation
user experience (UX) needs to be at the heart of your design decisions. It’s not just about how your website looks — it’s about how easily your visitors can browse, click, read, and act.

Start with Mobile-First Design

According to Google, in 2025, more than 50% of global web traffic now comes from mobile devices. If your website isn’t optimized for smartphones and tablets, you’re likely losing potential customers before they even read your headline. Make clean layouts, readable text, and easy navigation.

Optimize for Core Web Vitals

Google’s Core Web Vitals impact your SEO and user retention. At the very least, aim for Page load time under 3 seconds, Stable visual elements (no unexpected shifts) and Responsive interactivity (buttons respond fast when tapped).

Simplify Navigation for Real Users

Think of good navigation as a silent salesperson, helping users find exactly what they need without frustration.
Here’s how you can do it:

Use breadcrumb trails so users know where they are
Ensure touch targets (like buttons) are spaced for fingers, not just mouse clicks
Keep menus simple and intuitive — no endless dropdowns or hidden links

4. Build a Secure & Trustworthy Site

Users today expect a safe browsing experience — and search engines reward secure websites too.

Implement SSL/TLS Across the Entire Site

An SSL certificate encrypts data between your site and your visitors — essential for protecting sensitive information like contact forms, login credentials, or payments.

Enforce HTTPS

It’s not enough to install SSL. Force HTTPS across all pages from top to bottom. Set up automatic redirects from HTTP to HTTPS to ensure every visit is secure, no matter how someone lands on your site.

Secure All Logins

Your login page is a common target for attackers. You can harden it with simple steps: Enable Two-Factor Authentication (2FA), Limit Login Attempts, and Use Strong Password Policies.

Add Essential Security Layers

To build a website that supports long-term business growth, you also need proactive protection:
Web Application Firewall (WAF) – Blocks malicious traffic before it reaches your site.

Malware Scanning – Regular scans help detect and remove threats quickly.
Offsite Backups – Back up your website daily to a remote location — so you can recover quickly if anything goes wrong.
Uptime Monitoring – Get alerted the moment your website goes down and minimize disruptions to your business.

5. Set Up a Strong Technical SEO Foundation

Even the most beautiful, feature-packed site won’t perform if search engines can’t crawl, understand, and rank it properly. Let’s break down what a strong technical SEO foundation actually looks like and how you can put it in place.

Add a sitemap and robots.txt to guide Google on what to crawl.
Use schema markup to help content appear with rich results (like ratings or FAQs).
Write clear titles and meta descriptions — they’re what users see in search results.
Focus on speed, mobile-friendliness, and Google’s Core Web Vitals.
Use Search Console to track visibility and fix issues.
Good technical SEO makes sure your website gets found — and stays found.

6. Show Trust & Track Performance

Your website has to feel safe. If it doesn’t, visitors won’t stick around long enough to become customers. You can instantly boost trust by displaying trust signals like visible SSL certificates, payment security badges, or “verified by” icons from trusted providers.

These small visual cues create big confidence.

Track what’s working (and what’s not)

Once your site is live, don’t leave it on autopilot. Start by setting up the basics: Google Analytics to track visitors, Search Console to monitor rankings, and real-time monitoring tools like Hotjar or Clarity to see how users behave.

7. Keep Optimizing & Maintaining

Don’t treat your website as a one-time project. A well-maintained site performs better, ranks higher, and offers a smoother experience for users. Run monthly speed and security checks, making sure your pages load fast. Every quarter, test how your site looks and works across different devices and browsers. And every six months, audit your SEO, refresh your Core Web Vitals, and update or remove outdated plugins and themes. This regular upkeep keeps your site fast, reliable, and ready to grow your business.

Case Study: How We built an E-Commerce Website that Triple Online Sales

One of our clients ran a successful retail business but their website wasn’t bringing in results. It was slow, hard to navigate, and users often dropped off before completing a purchase.
We stepped in to rebuild the e-commerce site with clear goals faster performance, easier navigation, and a smoother checkout experience. We used a modern tech stack, cleaned up the product structure, and made the site mobile-friendly. We also integrated real-time stock updates and a reliable payment system. We’ve added a dynamic product recommendation engine powered by basic AI models to improve user engagement.
We didn’t overcomplicate it — just fixed what mattered.

After launch:

Sales from the website tripled in 60 days
Drop-off during checkout went down by over 50%
The site now loads in under 2 seconds, even on mobile
Customer support tickets related to the website dropped significantly

Focus on speed, usability, and reliability. The results will follow just like they did for this client.

5 Critical Website Failures Your Business Can’t Ignore
Even the best looking websites fail to grow if key issues go unchecked. Let’s fix all the issues hurting your traffic, leads, and trust.

Why is my website loading so slowly, and why does it matter? If your website takes more than 3 seconds to load, over 50% of your users will leave. How to fix: Compress images, use browser caching, enable a CDN, and minify code.
Is my website secure enough? If you're missing SSL or running outdated plugins, it will risk losing your data. Search engines also penalize unsecured websites. How to fix: Use HTTPS, install a Web Application Firewall, enable 2FA, and update software regularly.
Why aren’t visitors filling out our forms? Often, it’s because your forms are too complicated, glitchy, or hard to use on mobile. How to fix: Cut down fields, enable auto-fill, use mobile-friendly input, and add real-time validation.
Does my mobile site experience affect conversions and SEO? Absolutely. Over 60% of traffic is from mobile now. If your mobile UX or navigation is clunky, you’ll see higher bounce rates and lower rankings. How to fix: Use a mobile-first design, large buttons, simple menus, and test on real devices.
What if we ignore technical SEO? Search engines won’t find or rank your site properly. That means less organic traffic, fewer leads, and more ad spend to compensate. How to fix: Set up sitemaps and robots.txt, use schema, clean URLs, and optimize metadata.

Top Web Development Company
When you're investing in a business website, it shouldn't just sit there, it should bring results. That's why we focus on building websites that help to grow your businesses.
At Bluetick, we build high-performance websites using modern technologies like WordPress, Shopify, Webflow, Jamstack & Headless CMS.
We’re a web development company trusted by startups and enterprises across industries. Our websites load fast, scale easily, stay secure, and work as hard as you do.
You get direct access to senior developers, business-first solutions, clear timelines, honest communication and proven experience.

We understand how frustrating it is to pour money into a website that doesn’t deliver. That’s why every line of code we write serves a purpose: better performance, better leads, better business outcomes.
Whether it’s WordPress, Shopify, Webflow, Jamstack, or a Headless CMS, if you’re looking to build a website that works, not just exists, Bluetick is ready to build it with you.

Ready to launch a modern website that delivers real results? Let’s talk about the right tech stack for your business.

Book a free consultation with the Bluetick team.

DEV Community: Bluetick Consultants Inc.

Your iPhone App on the iPhone Duo: What Breaks, What to Fix, and What It Costs

What we’re solving

How much of the screen you get depends on how you last built the app

Two things the early headlines got wrong

A real example

How it works (with code)

The habits that break on a folding iPhone

What the fix looks like

A small audit script to size the job before the simulator arrives

What it costs

Cost options compared

The hidden cost: a bigger test matrix

Pros and cons

In favour of doing the work now

Against, or at least against rushing

Key takeaways

Frequently asked questions

What happens to an old iPhone app on the iPhone Duo?

Which SDK do I need for my app to fill the iPhone Duo screen?

Is the Xcode 27.1 beta with the iPhone Duo simulator available yet?

What code patterns break on the iPhone Duo?

How long does it take to prepare your app for iPhone Duo?

Does preparing for the iPhone Duo cost anything beyond engineering time?

Database Indexing in Ruby on Rails: When, Why, and How

Who This Guide Is For

When to Use This Advice

Use Cases This Guide Covers

Understanding How Databases Search Data

Without an Index

With an Index

What Exactly is an Index?

Working Example

Without an Index

Adding an Index

Composite Indexes

Partial Indexing

Partial Index vs Regular Index

Example

Achieving Zero Downtime While Adding Indexes

Why disable_ddl_transaction!?

Benefits

Verifying the Index

The Hidden Cost of Too Many Indexes

Drawbacks of Excessive Indexing

Production Case Study

Best Practices

Frequently Asked Questions

When should I add a database index in Rails?

What is the difference between a composite index and a partial index?

Does add_index lock the table in PostgreSQL?

Why is PostgreSQL not using my index?

Can too many indexes slow down a Rails application?

Final Thoughts

Beyond the Chatbot: What the New Digital Coworkers Actually Do, and What They Cost

The problem

What we are solving

A real example

Grok Bot, from xAI

Warmwind OS, from Warmwind AG in Jena, Germany

How it works, and the maths that decides whether it helps

How reliable is a multi-step AI agent?

What those numbers mean in practice

What it costs

Pros and cons

What genuinely works

What genuinely does not

Key takeaways

Frequently Asked Questions

What is an agentic AI digital coworker?

How much does agentic AI cost in 2026?

Why do agentic AI agents fail on long tasks?

Should we choose Grok Bot or Warmwind OS?

Is 2027 the year agentic AI takes over?

What does agentic AI not solve?

AI-native SDLC in a regulated, multi-vendor delivery estate

The first assumption: intent arrives clean

The second assumption: one company owns the chain

The thing underneath all of it

Where the human signatures go

Why `disable_ddl_transaction!`?