DEV Community: Bluetick Consultants Inc.

TikTok’s new AI shopping helper and one-click checkout, explained

Bluetick Consultants Inc. — Fri, 09 Oct 2026 10:30:27 +0000

Published: 9 October 2026 | Updated: 9 October 2026

Short answer: The TikTok AI shopping assistant is a chat window on a brand’s product page that answers questions about sizing, delivery and stock. Buy Direct is a one-click checkout in the For You feed. TikTok announced both on 5 October 2026.

Bottom line: Both are in limited testing with selected brands, and TikTok has not published a fee. Shops should get the fee in writing before building anything.

The problem

You are watching a video. Someone is wearing a pair of hiking boots you like, so you tap the ad. Then the chore begins. A new website loads slowly. You hunt for the size chart. You cannot tell whether they deliver to you or how long it takes. You are asked to create an account, then to type in your address and your card number on a small screen.

Most people give up somewhere in that list. You do not get the boots, and the shop loses a sale it had almost made. TikTok says the same thing in its own words: interest that starts with a video can fade once shoppers have to leave to hunt for details, and too many steps at the till make people abandon the purchase altogether.

What we’re solving

On Monday 5 October 2026, at Advertising Week in New York, TikTok announced two features aimed at those two drop-off points: unanswered questions and a slow till.

Shopping Assistant is a chat window that sits on a brand’s product page inside TikTok. You ask it things like “do these run small?” or “when would they arrive?” and it answers in plain sentences. TikTok calls it a conversational AI agent, which simply means software you can talk to that keeps track of what you have already said.
Buy Direct is a one-click purchase from the For You feed, the main stream of videos TikTok picks for you. It uses the payment card and address you have already saved, and you can track the order inside the app.
The brand stays the seller. TikTok says brands remain the “merchant of record”, meaning the business that is legally responsible for the sale, the refund and the tax. That is the main difference from TikTok Shop, where TikTok runs the marketplace.
Partners named: Salesforce, Shopify, Shoplazza and Stripe, which supply the shop and payment systems behind it.

What it does not solve

It is not available to everyone. Many headlines say TikTok “rolls out” these tools. TikTok’s own business blog says they are offered through “eligibility-based testing”, and brands must ask their TikTok sales contact whether they qualify. No list of countries or dates has been published.
The assistant is not an independent adviser. Its answers are built from information the brand supplies. Treat it like a well-informed shop assistant, not like a neutral reviewer.
The two features are separate. In the assistant flow TikTok describes, you still pay on the brand’s own website, opened inside TikTok. The one-click part is Buy Direct only.
It does not help you decide whether you need the thing. It removes steps. It does not add second thoughts.

A real example

Honest caveat first: TikTok has published no results from its tests, and no brand has yet reported numbers. So the best real evidence is what TikTok already sells, and what happened to the closest earlier attempt.

TikTok’s own illustration: you see an ad for hiking boots and wonder whether the material will hold up on granite trails, whether they fit true to size, and what colours exist. The assistant answers on the spot, and you carry on to pay.
TikTok already sells a lot. TikTok Shop opened in the US in September 2023. Research firm eMarketer estimates it made about $15.8 billion in US sales in 2025, roughly 18% of all US shopping done through social apps.
People do buy after watching. A report TikTok published the week before says 54 million Americans have bought a product after seeing it in a TikTok video.
The cautionary tale is ChatGPT. OpenAI launched Instant Checkout inside ChatGPT in September 2025, with Shopify, Etsy and Stripe on board. By March 2026 it was scaling the feature back. Reports put the number of Shopify shops that ever went live at somewhere between a dozen and about 30. People were happy to research products in the chat. They did not finish paying there.

Side by side, from published reports as of 6 October 2026:

	ChatGPT Instant Checkout	TikTok Buy Direct
Where you buy	Inside a chat conversation	Inside the video feed
Launched	September 2025	Announced 5 October 2026
Status today	Scaled back in March 2026	Limited testing with eligible brands
Fee to the shop	4% of the sale, as reported in January 2026	Not published
Who is the seller	The shop	The shop
Results so far	Weak uptake by shops and buyers	None published

Why TikTok might do better: people open ChatGPT to ask questions, but they already buy on TikTok. Why it might not: nobody outside TikTok has seen the numbers yet.

How it works (with code)

Buy Direct needs the brand’s shop to speak a shared language with TikTok. That language is the Universal Commerce Protocol, or UCP. It is an open standard that Google introduced in January 2026. Think of it as a universal plug socket: any app that follows the standard can plug into any shop that follows it, without a custom adapter for each pair.

Step 1: the app tells the shop which item you want. The shop opens an order and replies “incomplete”, because it does not yet know where to send it.
Step 2: the app sends your saved address. The shop works out delivery and tax and replies with a final total.
Step 3: the app sends a payment token, a one-time stand-in for your card so the real number is never passed around. The shop charges it and replies “completed” with an order number.
Why it feels like one click: TikTok already holds your address and card, so it can send all three messages back to back.

The short Python program below acts out the shop’s side of those three steps. It is a simulation based on Google’s published UCP checkout guide, not TikTok’s own code, which is not public. Sign-in, card handling and network calls are left out.

# A pretend brand's checkout, following the UCP steps a one-click buy goes through.
PRICES = {"trail_boot": 12900} # cents, from the brand's own product list
TAX_RATE = 0.08 # made-up rate, for the demo only

def create(item_id, qty): # POST /checkout-sessions
    line = {"item": {"id": item_id}, "quantity": qty}
    return {"id": "sess_1", "status": "incomplete", "line_items": [line],
            "subtotal": PRICES[item_id] * qty}

def update(s, postal_code, shipping=600): # PUT /checkout-sessions/{id}
    tax = round(s["subtotal"] * TAX_RATE)
    s.update(ship_to=postal_code, shipping=shipping, tax=tax,
             total=s["subtotal"] + shipping + tax, status="ready_for_complete")
    return s

def complete(s, payment_token): # POST /checkout-sessions/{id}/complete
    if s["status"] != "ready_for_complete":
        raise ValueError("address and payment must be set first")
    s.update(status="completed", order_id="ORD-1001")
    return s

# One click: the app already holds the saved address and card, so it sends all three.
s = create("trail_boot", 1)
print("1.", s["status"], "| subtotal $%.2f" % (s["subtotal"] / 100))
s = update(s, "94043")
print("2.", s["status"], "| total $%.2f" % (s["total"] / 100))
s = complete(s, "tok_saved_card")
print("3.", s["status"], "| order", s["order_id"])

Output when run:

1. incomplete | subtotal $129.00
2. ready_for_complete | total $145.32
3. completed | order ORD-1001

The three functions match the three messages above: open the order, add the address, take the payment.
Prices are held in cents (12900 means $129.00), which is how the real standard does it, to avoid rounding slips.
The total of $145.32 is $129.00 for the boots, $6.00 delivery and $10.32 tax. The 8% tax rate and the $6.00 delivery are made up for the demo.
The shop refuses to finish the order unless the address and payment step has happened first. That check is the shop’s protection against a half-filled order.
Notice who does the sums: the shop, not TikTok. That is what “the brand stays the seller” means in practice.

What it costs

For shoppers, both features are free to use. The cost is indirect: the easier it is to pay, the easier it is to overspend.

For shops, the honest answer is that TikTok has not published a fee for Buy Direct or Shopping Assistant. The table below shows what is known for each realistic route, including doing nothing. All figures are in US dollars, for US sellers, checked on 6 October 2026.

Option	Platform fee	Card processing	Hidden costs	Best for
Do nothing: send shoppers to your own site	$0	2.9% + $0.30 per sale (Stripe standard rate)	Shoppers who give up on the way	Shops with a fast site and loyal buyers
Sell through TikTok Shop	6% on most categories in TikTok’s public fee table. Seller guides report 8% since 4 August 2026	Included in the fee	Creator commissions you set, refund charges, less control	Shops that want TikTok to run the store
Buy Direct	Not published	Your own processor’s rate, since you remain the seller	Building the UCP connection, ad spend, getting accepted into testing	Brands already on Shopify, Salesforce or similar, selling impulse-priced items
Shopping Assistant	Not published	Your own, since payment happens on your site	Keeping product details accurate and current, ad spend	Products that attract lots of questions
For reference: ChatGPT Instant Checkout (scaled back March 2026)	4%, as reported	About 2.9% + $0.30 on top	Very few buyers finished paying	Reference only

What that means on a $50 order

Your own site: about $1.75 in card fees.
TikTok Shop: $3.00 at 6%, or $4.00 if the reported 8% rate applies to you. Add whatever commission you offer creators.
ChatGPT Instant Checkout, when it ran: about $3.75.
Buy Direct: unknown. Expect at least the $1.75 in card fees, because you are still the seller. Whether TikTok adds its own cut on top is the question to ask your sales contact.

Costs that are not on the invoice

Setup time. If your shop runs on one of the named partner platforms, much of the connection may be handled for you. If it is custom-built, a developer has to build it.
Data upkeep. The assistant repeats what you tell it. A stale delivery time or a wrong size chart becomes a wrong promise to a customer.
Disputes. You remain the seller, so chargebacks land on you. Stripe’s standard charge is $15.00 per dispute received.
Dependence. Sales that happen inside TikTok depend on TikTok’s rules and fees, which it can change.

Which option suits whom

Solo seller: stay as you are or use TikTok Shop. You are unlikely to be in the test group yet.
Small team: ask your TikTok contact about eligibility, but do not build anything until the fee is in writing.
Large brand: worth a test, with a clear measure of extra sales against extra cost.

Pros and cons

Pros

Fewer steps for shoppers. No new website, no re-typing a card number.
Questions get answered at the moment you have them, about the thing you are looking at.
Brands keep the sale and the legal relationship, unlike a marketplace listing.
It is built on an open standard backed by large shops and payment firms, so the work a brand does for TikTok may be reusable elsewhere.
TikTok starts from real buying habits, which ChatGPT did not have.

Cons

It makes impulse buying easier. An April 2026 opinion piece in the Michigan Journal of Economics argued that TikTok’s mix of persuasive videos and instant purchase already pushes people to buy without comparing or thinking it over. One-click checkout removes one more pause.
The adviser works for the seller. The assistant’s answers come from the brand’s own information, and TikTok has not said what model powers it or how it handles a question the brand would prefer not to answer.
The price is unknown. No fee has been published, and it is not clear who carries the risk when a payment is disputed.
The last big attempt flopped. ChatGPT’s in-chat checkout was scaled back within about six months.
Most brands cannot use it yet. It is a limited test, with no public timetable.
It suits cheap, quick purchases best. Someone buying a $2,000 item compares, reads reviews and often phones first. One click is not what holds them back.
Open questions for brands. TikTok has not said how much customer information, such as an email address, the brand receives after a Buy Direct sale.

Key takeaways

TikTok announced two things on 5 October 2026: a chat helper that answers product questions, and a one-click checkout in the video feed.
Both are in limited testing with selected brands. This is not yet something every user or every shop will see.
The brand stays the legal seller, which sets this apart from TikTok Shop.
The assistant is fed by the brand. It is a salesperson, not a reviewer.
TikTok has not published what it charges. Shops should get that in writing before building anything.
A similar idea inside ChatGPT was scaled back after about six months. TikTok’s advantage is that people already shop there, but there are no results yet to prove it.

Frequently asked questions

What is the TikTok AI shopping assistant?

Shopping Assistant is a chat window on a brand’s product page inside TikTok. It answers questions about sizing, delivery and stock using information the brand supplies.

What is TikTok Buy Direct?

Buy Direct is a one-click purchase from the For You feed. It uses the payment card and address you have already saved, and you can track the order inside the app.

Is TikTok Buy Direct the same as TikTok Shop?

No. In TikTok Shop, TikTok runs the marketplace. With Buy Direct, the brand stays the merchant of record, so it remains legally responsible for the sale, the refund and the tax.

Who can use the TikTok AI shopping assistant and Buy Direct?

Both are offered through eligibility-based testing. Brands must ask their TikTok sales contact whether they qualify. No list of countries or dates has been published.

How much does TikTok Buy Direct cost shops?

TikTok has not published a fee. Because the brand stays the seller, shops should expect at least their own card processing cost, which is 2.9% + $0.30 per sale on Stripe’s standard rate.

What is the Universal Commerce Protocol?

The Universal Commerce Protocol, or UCP, is an open standard that Google introduced in January 2026. It lets any app that follows it complete a checkout with any shop that follows it. Buy Direct needs it.

The post TikTok’s new AI shopping helper and one-click checkout, explained appeared first on Bluetick Consultants Inc..

Dazzle: the AI assistant that reads your photos instead of your inbox

Bluetick Consultants Inc. — Thu, 08 Oct 2026 08:44:44 +0000

Published: 8 October 2026 | Updated: 8 October 2026

Short answer: The Dazzle AI assistant is a personal AI assistant from Marissa Mayer’s startup, Dazzle AI, launched on 29 September 2026. It learns about you from your camera roll instead of your email. It turns recent photos into tasks and older photos into ideas.

Bottom line: The Dazzle AI assistant is free for now, invite-only and iPhone only. The real cost is your photos, which are stored on Dazzle’s servers. Start with selected photos, not full access.

The problem

You open an AI chat app and it greets you with an empty box. It knows nothing about you. So before it can help, you have to explain yourself: who your family is, what you like, what your budget is, what you did last time. Every single time.

Some newer assistants try to fix this by reading your email and calendar. That helps with work. It does not help much with real life, because your inbox does not know your daughter loves skating or that your garage door is broken.

Meanwhile, the answers are already sitting on your phone. You photographed the broken door. You took a screenshot of the jacket you wanted. You have six years of holiday pictures. None of it is doing anything.

What we’re solving

Dazzle is a personal AI assistant launched on 29 September 2026 by Dazzle AI, the startup founded by former Yahoo chief executive Marissa Mayer. Its pitch is three words: pictures, not prompts.

What it removes: the blank box. Dazzle builds its picture of you from your camera roll, so you do not have to type out your life story first.
Get It Done: it looks at recent photos and screenshots and asks why you took them. A flyer becomes a calendar entry. A flat tyre becomes a repair booking. A jacket becomes a place to buy it.
Ideas: it uses your older photos to suggest restaurants, concerts, trips and gifts that fit your taste.
Chat: a normal AI chat, but one that already knows your context. Dazzle says it runs on “frontier models”, meaning the most capable AI models from the big labs. It does not say which ones.
Where it lives: an iPhone app, iMessage and text, and the web at dazzle.ai.

What it does not solve:

It is not open to everyone. As of 5 October 2026 the site says “currently invite-only”.
There is no Android app listed. The only app link is the Apple App Store.
It does not read your email, messages or bank. That is deliberate, but it also means it misses whatever you never photographed.
It does not act alone on money. Dazzle says purchases and bookings need your explicit approval.
It is not fully automatic yet. The company says human support staff step in on complicated tasks “for now”.

A real example

Dazzle is one week old, so there are no long-term customer stories yet. The best evidence so far is a hands-on test by TechCrunch reporter Marina Temkin, published on launch day, plus what Mayer says about her own use.

Mayer’s own use: she says Dazzle worked out from her photos that her family loves escape rooms. It then suggested several San Francisco Bay Area venues she had never heard of.
What worked for the reporter: asked for holiday ideas, Dazzle suggested Mediterranean spots, likely because of her past trips to Spain and Greece. It also suggested a local pottery studio and a night kayak tour, which she liked.
What did not: it recommended Sicily, where she had already been four years earlier. And when she asked whether to buy her daughter roller skates, it did not know the girl could already skate.
Her verdict: the ideas felt more personal than what an email-and-calendar assistant gives. But she was undecided on whether she would keep using it, and wrote that Dazzle “isn’t as broadly useful as other offerings quite yet”.

That is one reviewer and one founder. Treat it as an early signal, not proof.

How it works (with code)

Dazzle has not published its internal code. What it has published is the outline: photos are uploaded to its servers, sensitive ones are thrown away, the rest are analysed to build a profile, and recent ones are checked for tasks. The short Python example below is our own simplified sketch of that idea, not Dazzle’s code. It uses plain text labels in place of real image analysis so anyone can run it.

from collections import Counter

# Each photo is described by labels an image model might produce.
photos = [
    {"id": 1, "labels": ["ski", "mountain", "family"]},
    {"id": 2, "labels": ["passport", "document"]},
    {"id": 3, "labels": ["escape room", "family"]},
    {"id": 4, "labels": ["flat tire", "car"]},
    {"id": 5, "labels": ["ski", "snow"]},
    {"id": 6, "labels": ["event flyer", "date"]},
]
SENSITIVE = {"passport", "document", "bank statement", "prescription"}
ACTIONS = {
    "flat tire": "Find a tyre repair shop",
    "event flyer": "Add the event to your calendar",
}

# Step 1: drop anything that looks sensitive before learning from it.
kept = [p for p in photos if not SENSITIVE & set(p["labels"])]

# Step 2: count what shows up most. That becomes the profile.
profile = Counter(label for p in kept for label in p["labels"])

# Step 3: treat each remaining photo as a possible to-do.
todos = [ACTIONS[l] for p in kept for l in p["labels"] if l in ACTIONS]

print("Photos kept:", len(kept), "of", len(photos))
print("Top interests:", [label for label, n in profile.most_common(2)])
print("Get It Done:", todos)

Output when we ran it:

Photos kept: 5 of 6
Top interests: ['ski', 'family']
Get It Done: ['Find a tyre repair shop', 'Add the event to your calendar']

What that code is doing, in plain words:

Each photo is reduced to a few labels, such as “ski” or “flat tire”. In the real product an AI model that can read images does this part.
Step 1 throws out the passport photo before anything is learned from it. This mirrors Dazzle’s stated rule: “When in doubt, we leave it out.”
Step 2 counts what appears most often. Two ski photos and two family photos become “this person likes skiing and family time”.
Step 3 treats each remaining photo as a possible job. The flat tyre and the flyer each turn into a suggested action.
The real system is far more complex. Dazzle lists seven patent applications, covering things like building a map of places and a map of relationships from photos.

If you already use another AI agent

Dazzle offers a connector so other agents can use what it has learned from your photos. It names Claude, Codex, OpenClaw and Hermes.
The connector uses MCP (Model Context Protocol), a common standard that lets AI tools plug into outside data sources.
For OpenClaw the published install command is one line. We could not run it here, because it needs the OpenClaw tool and a Dazzle account:

clawhub install dazzle-photo-intelligence

What it costs

Prices are in US dollars and were checked on 5 October 2026. Dazzle has no pricing page. The “free for now” figure comes from Mayer’s launch-day interview with CNBC, where she said transaction fees or a subscription may come later. Meta Muse prices were confirmed by Meta to CNBC. Instinct publishes no prices.

Option	Upfront cost	Ongoing cost	Hidden costs	Best for
Do nothing: keep typing prompts	$0	$0 on free chat apps	Your time. You re-explain yourself in every chat	Anyone not ready to share personal data
Dazzle	$0	Free for now. Fees or a subscription may come later	Your photos are stored on Dazzle’s servers. Invite wait. iPhone only	iPhone users who want ideas and errands from photos
Meta Muse	$0, but a payment card is asked for at sign-up	Free tier, then $20 or $100 a month by usage	Connects to email, calendar and payments. US only at launch	People who want an agent across email and bills
Instinct	$0	Free during invite-only beta. No published price	Very broad account access. Documented security incidents in beta	Early adopters comfortable with risk

How to read this table:

Free is not the same as free forever. Dazzle raised $8 million in seed funding at a $35 million valuation. Storing and analysing whole photo libraries costs real money, so a price is likely.
The real payment today is data. Dazzle’s own developer page says it “processes and stores your photos on our servers”.
Solo user: try Dazzle with a hand-picked set of photos, not the full library. It costs nothing and limits what you share.
Family: remember your photos contain other people. They did not agree to be analysed.
Business or team: nothing here is built for work. Dazzle is aimed at personal life.
Readers outside the US: the text line is a US-style short number (742213) and Meta Muse is US only. We could not confirm whether Dazzle invites are being issued in India or elsewhere.

Pros and cons

Pros

No cold start. It has context from the first minute, without a long setup chat.
Covers home life. Photos capture hobbies, kids, trips and repairs, which email mostly misses.
Narrower access than rivals. It does not ask for your passwords, inbox or messages. Dazzle says its agent uses its own accounts and acts “on your behalf, not as you”.
You choose the scope. Full library, selected photos, or no photo access at all.
Clear promises on data use. Dazzle says personal data is not used to train public AI models, not used for third-party advertising, and not sold.
Easy exit. Deleting your account deletes the synced photos from its servers, according to the company.

Cons

Your photos leave your phone. They are stored on company servers, which makes the company a target for hackers.
A camera roll is not harmless. Privacy site All About Cookies points out that screenshots often hold bank balances, one-time passwords, ID documents, medical reports and private chats.
“Sensitive” is loosely defined. Dazzle gives nudity and ID documents as examples. It does not say what happens when the filter misses something.
It gets things wrong. The TechCrunch test showed a repeat destination and a missed fact about the reviewer’s own child.
It is less capable than rivals today. That is the reviewer’s judgement, not ours.
Limited reach. Invite-only, and iPhone only for the app.
Unknown future price. You may build a habit around something that later charges.
Track record. Mayer’s previous startup, Sunshine, launched a photo-sharing app called Shine in 2024. It was criticised for dated design, did not catch on, and shut down.
Other people’s privacy. Friends, family and strangers in your photos get analysed too.

Key takeaways

Dazzle launched on 29 September 2026. It is an AI assistant that learns about you from your camera roll, not your inbox.
It does two main things: turns recent photos into tasks, and turns old photos into personal suggestions.
It is free for now, invite-only, and iPhone only. A fee or subscription may come later.
The real cost is your photos, which are stored on Dazzle’s servers. Start with selected photos, not full access.
Early testing shows personal, useful ideas alongside clear mistakes. It is promising, not proven.
If you already use an AI agent, Dazzle can plug into it, so you do not have to switch.

Frequently asked questions

What is the Dazzle AI assistant?

The Dazzle AI assistant is a personal AI assistant from Dazzle AI, the startup founded by former Yahoo chief executive Marissa Mayer. It launched on 29 September 2026 and learns about you from your camera roll instead of your email.

Is the Dazzle AI assistant free?

Yes, for now. Dazzle has no pricing page, and Marissa Mayer has said transaction fees or a subscription may come later.

Is Dazzle available on Android?

No Android app is listed. Dazzle works through an iPhone app, iMessage and text, and the web at dazzle.ai. It is currently invite-only.

Is it safe to give Dazzle access to your photos?

It carries real risk. Your photos are stored on Dazzle’s servers, and camera rolls often hold screenshots of bank balances, ID documents and private chats. Share selected photos rather than your full library.

Does Dazzle work with Claude and other AI agents?

Yes. Dazzle offers an MCP connector so agents such as Claude, Codex, OpenClaw and Hermes can use what it has learned from your photos.

The post Dazzle: the AI assistant that reads your photos instead of your inbox appeared first on Bluetick Consultants Inc..

Meta Muse vs Instinct: Two AI Helpers That Run Your Errands, and Why Muse Is the Safer Bet

Bluetick Consultants Inc. — Thu, 01 Oct 2026 11:56:56 +0000

The problem

You have a list of small jobs that never ends. Cancel that gym membership. Book a table for Friday. Find a cheaper phone plan. Reply to the email from the landlord. None of them is hard. Together they eat your evenings.

Chat apps like ChatGPT can tell you how to do these things. They cannot do them for you. You still open the website, type the password, click through the forms, and wait on hold.

This year, a new kind of app arrived that promises to actually do the jobs. You hand it a task, it goes off and finishes it, and it messages you when it is done. The catch is obvious: to do your errands, it needs the keys to your email, your calendar, and sometimes your bank card. So the real question is not “which one is cleverer?” It is “which one can I trust with my keys?”

What we’re solving

The tech name for these apps is “AI agents”: software that takes actions on your behalf instead of just answering questions. Two of them are getting the most attention right now:

Meta Muse : Meta’s personal agent, launched in the US on 8 September 2026. It runs on Meta’s own AI model, Muse Spark, and works on the web at muse.ai, on iOS and Android, and inside WhatsApp.
Instinct : an invite-only agent from a San Francisco startup (Spear Street Technology) led by 23-year-old former Sierra researcher Noah Shinn. You text it or call it through iMessage, WhatsApp or the phone. There is no app.

Both promise to take the same chores off your plate:

Booking restaurants, travel and appointments
Sorting and replying to email, managing your calendar
Shopping and checking out for you
Cancelling subscriptions and chasing cheaper bills
Phoning businesses for you (both added AI phone calls in September 2026)

What neither one solves:

They still make mistakes. Both companies say so.
Neither is fully open outside North America yet. Muse is available to adults in the US and Canada. Instinct is invite-only.
Neither removes the need to decide how much of your life you are comfortable handing over.

The core difference in one line: Instinct is built for maximum freedom to act. Muse is built so that the agent can act, but a separate guard decides what it is allowed to do and asks you before anything risky.

A real example

Both products have been used by real people in public, and their track records so far tell you a lot.

Instinct: loved for results, burned on trust

Early users praised it for booking travel, restaurant reservations, email follow-ups and even planning a wedding. The founder said users had “canceled hundreds of dollars of subscriptions.”
Its original terms of service gave the company a “perpetual and irrevocable” licence to use, store and publish users’ materials, including to train its AI. After a public backlash, the terms were rewritten on 26 August 2026 to drop that wording, but training on your data is still on by default.
Product leader Claire Vo disconnected Instinct from her Google account at 11 AM and still got a summary of her emails at 2 PM. Instinct told her the emails were stored in plain text for later searches.
Investor Katie Jacobs Stanton reported that it sent an email on her behalf without checking with her first. “One unauthorized action can reset that trust to zero,” she wrote.
Founder Alex Cohen tested whether a stranger’s email could trick it. It could, and he deleted his account.
None of this stopped investors: Instinct raised a $250 million Series B at a $2.5 billion valuation, and The Information reports talks for $1 billion more. It has over 100,000 users.

Muse: fast growth, with a published safety design

Muse passed 3.4 million downloads within about two and a half weeks, according to Sensor Tower estimates. It reached number one on the US App Store on 18 September and on Google Play on 19 September 2026.
On launch day, Meta published a detailed technical write-up of how Muse keeps passwords away from the agent and asks users before risky actions.
Meta opened a public bug bounty paying up to $300,000 for security flaws, including up to $130,000 for tricking Muse into misbehaving for a user.
It has had its own stumbles. WIRED’s reviewer said Muse “prioritizes data collection about me over actually accomplishing tasks,” and Business Insider reported it sent unapproved emails during Meta’s internal testing before launch.

How it works (with code)

Both agents get their own computer in the cloud with a web browser. You give them a job, and they click around websites and use your connected apps just like you would. The big difference is what happens to your passwords and who says “yes” before the agent acts.

Side by side

	Meta Muse	Instinct
Who can get it	Anyone 18+ in the US and Canada	Invite only, waitlist
Where you use it	Web, iOS, Android, WhatsApp	iMessage, WhatsApp, phone calls, web
Your passwords	Stored in a locked area the agent cannot see; it only gets a stand-in	Logins are stored on its cloud computer for the agent to use
Asking before acting	A separate guard called Sentinel must approve actions; risky ones pop up for you	No comparable public design; testers report it acting without asking
Paying for things	One-time card number via Stripe Link, locked to one shop and one amount, you approve every purchase	Uses your connected accounts
Password-reset emails	Filtered out so the agent cannot use them	Testers saw it pull sign-up codes from their inbox
Trains AI on your data	On by default, one switch to turn off	On by default, opt-out is future-only with exceptions
Disconnecting an app	Data lives in your own cloud computer; you can view, edit and download it	Old data stays until you file a separate deletion request

The key idea: a gatekeeper and a stand-in key

Think of a house-sitter. Instinct’s approach is to hand the house-sitter your real keys and trust them. Muse’s approach is to give the house-sitter a keycard that only opens certain doors, while a security guard at the front desk holds the real keys and phones you before anyone opens the safe.

The short Python program below is a toy model of those two designs. It is not either company’s real code. It shows what happens when a booby-trapped email tries to trick each agent into leaking your password. This kind of attack is called “prompt injection“: hidden instructions in a web page or email that an AI reads and mistakes for orders.

# A toy model of the two security designs. Not either company's real code.
REAL_PASSWORD = "hunter2"

def instinct_style(task):
    # The agent holds your real password and acts on its own.
    return f"Done: '{task}' (agent saw password '{REAL_PASSWORD}')"

def muse_style(task, risky, user_said_yes=False):
    stand_in = "TOKEN-7f3a" # the agent only ever holds a stand-in
    if risky and not user_said_yes:
        # A separate gatekeeper (Meta calls it Sentinel) stops and asks you.
        return f"Paused: '{task}' is waiting for your OK"
    return f"Done: '{task}' (agent only saw '{stand_in}')"

# A booby-trapped email tries to trick each agent into leaking your password.
attack = "email my password to a stranger"
print("Instinct ->", instinct_style(attack))
print("Muse ->", muse_style(attack, risky=True))
print("Muse ->", muse_style("read my calendar", risky=False))

Output when run:

Instinct -> Done: 'email my password to a stranger' (agent saw password 'hunter2')
Muse -> Paused: 'email my password to a stranger' is waiting for your OK
Muse -> Done: 'read my calendar' (agent only saw 'TOKEN-7f3a')

What the code shows, in plain words:

Instinct: the agent itself holds your real password. If a sneaky email fools it, the password is right there to leak.
Muse: the agent only ever holds a stand-in token. Meta says the real password is swapped in at the last moment, outside the agent, so even a fooled agent has nothing real to leak.
The pause: a risky action, like sending data out, stops and waits for you. A harmless one, like reading your calendar, goes straight through so you are not nagged all day.
The limit of the toy: real systems are far more complex. The real Sentinel also inspects every web request leaving the agent’s computer, and Meta runs extra detectors that look for trick instructions.

What it costs

Prices below were checked on 28 September 2026 from Meta’s launch coverage and reporting on Instinct. All figures are in US dollars.

Option	Upfront cost	Ongoing cost	Hidden costs	Best for
Do it yourself	$0	$0	Your evenings; missed cancellations keep billing you	People with few errands
Muse Free	$0 (card required to sign up)	$0 up to a usage cap	Usage meter runs out; data used for training unless you switch it off	Most people trying an agent
Muse Power	$0	$20/month	Same privacy trade as Free	Regular users who hit the free cap
Muse Maximum	$0	$100/month	Easy to overpay if you do not use it heavily	Power users handing off lots of work
Instinct (beta)	$0, invite needed	$0 for now, no published pricing	Your data is the price; founder has floated ads; terms allow paid features later	Early adopters who want maximum autonomy

What this means for you:

For a single person, Muse Free is the obvious starting point. It costs nothing, and the meter warns you before you run out.
Instinct is also $0 today, but “free with no business model” usually means you pay later, either in money or in data. Its founder has said he does not want to charge users and is considering advertising.
Meta says its own long-term plan is to take “a small fee from transactions” Muse makes for you, rather than ads based on your Muse data. It states Muse conversations are not shared with its ad systems, although sites Muse visits for you may still show you ads later.
Count the time cost too. Setting up either agent means connecting apps one at a time and reviewing each permission, which takes real time before you save any.

Pros and cons

Where Muse is better

You can actually get it. It is open to adults in the US and Canada today, with a free tier. Instinct needs an invite.
Your passwords never touch the AI. Meta’s design keeps real logins and payment cards in a separate locked area and gives the agent only stand-ins.
A guard that cannot be talked round. Sentinel is a separate program, not part of the chatbot, so tricking Muse does not switch the guard off.
Safer shopping. Every purchase uses a single-use card number locked to one shop, one amount and a short time window, and you approve each one.
Your email cannot be used to hijack other accounts. Muse filters out one-time codes, password-reset links and magic login links.
Fine-grained permissions. You can let it read your calendar without letting it write to it, and choose whether an approval is one-time, for one task, or permanent.
It shows its work. Meta published its security design and pays outside researchers to break it. Instinct’s team kept a low profile while its problems were reported.
Your data lives in one place you can inspect. Files, memory and connected-app logins sit in your own cloud computer, which you can view and download.

Where Instinct still wins

More raw autonomy. Reviewers describe it as the more aggressive finisher on long, messy errands such as negotiating bills or rebooking travel.
No new app to learn. It lives in your text messages and phone calls.
It is not Meta. For people who will not trust Meta with their inbox under any design, that matters more than any feature.

Muse’s real weak spots

Meta’s track record. Meta paid a record $5 billion FTC privacy penalty in 2019 and agreed an $18 billion settlement with 29 US states in August 2026. A well-written security document does not erase that history, and outside experts have not yet verified Meta’s claims.
Training is on by default. Your chats and task history are used to train Meta’s AI unless you switch off “Help improve our AI models” under Data Controls. Meta says it strips personal details first.
It keeps asking for more. WIRED found it repeatedly nudged the reviewer to connect email and banking. Inc. found it read a user’s private message notifications without being asked.
Meta can still access your data. Meta’s own write-up admits today’s design does not stop Meta staff from accessing data when needed to run the service. A “Confidential VM” that would block this is promised for later this year.
Mistakes still happen. Meta says plainly that tricking AI agents is “an open problem” and Muse “will sometimes make mistakes.”

Key takeaways

Muse and Instinct both do real errands for you, not just chat. The difference is how much they trust themselves.
Muse is the better choice for most people: it is available now, free to start, and built so the AI never sees your real passwords or card numbers and must ask before risky actions.
Instinct may finish more complicated errands, but it has already been caught keeping emails after disconnection, acting without asking, and falling for a planted email.
Muse is not risk-free. Turn off AI training under Data Controls, connect only the apps you need, and start with read-only access.
Cost is not the deciding factor today, since both can be used for $0. Trust is. Pick the one whose design you can check, and give it the keys one door at a time.

The post Meta Muse vs Instinct: Two AI Helpers That Run Your Errands, and Why Muse Is the Safer Bet appeared first on Bluetick Consultants Inc..

Google CC Wants to Be Your Family’s Chief of Staff. Here’s What It Does and What to Watch

Bluetick Consultants Inc. — Thu, 24 Sep 2026 12:18:24 +0000

TL;DR: The Google CC AI agent is an experimental assistant from Google Labs that, since September 17, 2026, can be shared by up to six household members. It turns the emails and files each member chooses to share into a daily brief, calendar events and a shared task list, and it can handle tasks such as filling out forms with your permission. It is available in the U.S. only, for adults 18+ with personal Google accounts. For business owners and IT teams, the bigger lesson is its design: its own identity, an isolated runtime, opt-in access, and separate shared and personal memory.

Last updated: September 24, 2026

A look at Google Labs’ new household AI agent, how it works, and what it could mean for families, business owners, and IT teams.

Every family runs something that looks a little like a small business.

There are schedules to manage, appointments to remember, forms to complete, shopping to do, and a never-ending list of small tasks that somehow become one person’s responsibility.

A school newsletter says a field trip form is due Friday. The soccer schedule changes in a group email at 9:47 p.m. The vet sends a reminder to one parent’s inbox, while the other parent never sees it.

None of these things is particularly difficult. The problem is that the information is spread across different inboxes, calendars, documents, and messages. Someone usually ends up keeping track of everything.

Google thinks an AI agent can help with that.

On September 17, 2026, Google Labs expanded CC, its experimental AI agent, from a personal assistant into an agent that can be shared by the entire household.

I have spent years looking at software products that promise to make people’s lives easier. What makes CC interesting is that it is not just another place to store information or write down tasks. It is trying to coordinate information and people and then take action on that information.

From a Morning Email to a Family Agent

CC is not a completely new product.

It started in late 2025 as a single-user Google Labs experiment that generated a morning “Your Day Ahead” briefing using information from Gmail, Calendar, and Drive. In May 2026, the idea moved into the Gemini app as Daily Brief.

The September release changes the product quite a bit.

Up to six family members can now share one CC , and the agent can do more than summarize information. It can actually act on it.

That is an important difference.

A useful household assistant should not just tell you that something needs to be done. Ideally, it should help you get it done.

What Does the Google CC AI Agent Actually Do?

In short, it collects what family members share, turns it into a shared daily brief, calendar entries and tasks, and handles some of the follow-up work itself.

According to Google’s announcement, CC takes the information a family shares with it and organizes it into three main areas:

A shared “Your Day Ahead” brief that shows who needs to be where and what is still pending.
Calendar entries that are created and updated automatically as plans change.
A shared task list with to-dos extracted from emails and documents.

It can also handle some tasks itself, with your permission. This is where CC starts to look more like an agent than a traditional family organizer.

For example, it can:

Fill out permission slips and activity registration PDFs
Create school-supply shopping lists
Plan weekly meals
Work out drive times between back-to-back activities
Create shared Google Docs and Sheets
Ask family members for missing information when something is unclear

Here is a simple example.

A school sends a permission-slip PDF to one parent’s inbox. CC can read the document, identify the field trip, add it to the family calendar, create a “sign form” task, fill out the relevant parts of the form, and mention it in the next morning’s briefing.

The other parent does not need to find the original email and forward it manually.

That is where the agent approach becomes useful.

Under the Hood: An Agent With Its Own Identity

As someone who writes about technology and systems, I find the architecture behind CC particularly interesting.

1. CC Has Its Own Google Account

CC is not simply a feature running invisibly inside a user’s account.

It has a verified Google identity of its own. When it appears in an inbox or a Chat thread, it is shown as a separate participant.

That is a useful design choice for an AI agent.

If an agent sends an email, changes a calendar event, or creates a document, users should be able to see that the action came from the agent. It makes the system easier to understand and gives users a clearer record of what happened.

2. It Runs on an Isolated Cloud Computer

Each CC instance runs in its own sandboxed cloud environment, powered by Gemini models and Antigravity, Google’s agentic harness.

Isolation matters when an agent is handling personal information.

A household agent could potentially deal with school information, appointments, family schedules, and other sensitive data. Keeping the agent’s environment isolated can help limit the impact if something goes wrong.

3. It Has Group Memory

CC separates information shared by the household from information that belongs to an individual family member.

This may sound like a small feature, but it solves a real problem for shared AI systems.

A family assistant needs to know what information is useful to everyone and what information only applies to one person.

For example, one family member’s dietary restrictions may matter when planning dinner for everyone. Their work travel schedule may not need to become part of the entire household’s context.

Can Google CC See Everything in Your Inbox?

CC does not automatically get access to everyone’s complete inbox.

Google says that “CC only sees what each member chooses to share.”

There are three ways to share information with CC:

Forward manually. Send a specific email, text, Drive folder, or calendar invitation to CC’s address. The name is quite literal. You can simply CC the agent.
Auto-CC trusted senders. Choose senders such as a school district, sports club, or airline whose messages should automatically go to CC.
Approve new senders weekly. CC can suggest new senders that it could track, and family members can approve or decline them.

Each family member controls their own sharing. CC also only responds to group members, and Google says it will not take action or share information outside the group without a member’s permission.

That is a reasonable approach for a shared assistant because it does not require everyone to give the agent unrestricted access.

There is still something families need to think about.

Once someone shares information with a shared household agent, that information becomes part of the context available to the household assistant. Families should be comfortable with that before automatically sharing messages from particular senders.

The Limitations

CC is still a Labs experiment, and there are several limitations worth knowing about.

U.S. only for now.
Adults only, 18+ , and a personal Gmail account is required. Teens cannot join, even though they may have some of the busiest schedules in the household.
School-issued accounts are not supported. This is notable because many schools use Google Workspace for Education. Messages from those accounts have to be forwarded from a parent’s personal account.
Waitlist access. Existing CC users receive an upgrade invitation. Other users can join the waitlist through Google Labs.
No pricing has been announced. Google has not said whether CC will remain free, become part of a Google One AI plan, or eventually become a separate product.

These limitations are important because they show where CC stands today.

It is an experiment with a fairly narrow audience, not yet a general-purpose household platform.

The Competition

Google is not the first company trying to solve this problem.

Startups such as Ollie , which focuses on privacy, and Fambot , which describes itself as an AI chief of staff for families, are working on similar problems. Earlier family-organizing products such as Ohai.ai have also tried to make household coordination easier.

Google has one obvious advantage.

It already has many of the services a household agent needs, including Gmail, Calendar, Drive, and Maps.

A startup has to convince users to connect all of those services. Google already has them.

There is a tradeoff, though. Using CC means putting even more of a family’s day-to-day information into Google’s ecosystem.

What This Means for Business Owners and IT Teams

CC is a consumer product. Google has positioned it around personal Gmail accounts and households of up to six people. Workspace accounts are not currently supported.

So why should business owners and IT teams pay attention?

Because several of the ideas behind CC can also be applied to business automation.

1. Founders and Small-Business Owners Can Use It for Home Logistics

For many small-business owners, personal and work schedules are closely connected.

A child’s sports practice can determine when a supplier meeting can happen. A missed school form can consume an afternoon. A family appointment can affect the rest of the working day.

Using CC for the home side of that equation can help reduce some of that administrative work.

The important boundary is simple.

Use CC for family logistics, not customer or company data.

Invoices, customer emails, contracts, payment information, and other confidential business information should not be sent to a consumer AI experiment.

2. Copy the Auto-CC Pattern for Business Workflows

The most interesting idea in CC may not actually be the AI.

It is how information gets into the system.

The agent receives information from the places where that information already arrives. Nobody has to type the same information into another system.

Businesses can use the same idea.

| Family Use in CC | Business Equivalent |
| Auto-CC the school district | Automatically forward vendor invoices to a shared accounts-payable inbox so an AI can identify due dates |
| “Your Day Ahead” family brief | A daily team brief containing deliveries, follow-ups, and meetings |
| Filling out permission slips | Pre-filling onboarding documents, vendor registrations, and compliance checklists |
| Drive time between activities | Route and schedule planning for field staff, deliveries, and service calls |
| Shared grocery list | Shared inventory and stock-reorder list |

There is no need to wait for a product called “CC for Business.”

The Gemini features available through Google Workspace, Microsoft 365 Copilot, and automation platforms such as Zapier and Make can already implement many of these workflows when configured with the right business controls.

The important idea is the workflow, not the product name.

3. Use the Architecture as a Blueprint for Your Own AI Agents

If your IT team is building or evaluating AI agents, CC has several design choices worth studying.

Give the agent its own identity.

CC has its own verified account instead of silently using a user’s identity. Business agents should follow a similar model by using dedicated service accounts or identities. That makes it easier to trace and audit actions such as emails, calendar changes, and document updates.

Isolate where the agent runs.

CC runs in an isolated cloud environment. Business agents should also operate in environments with limited permissions rather than having unrestricted access to shared infrastructure.

Make access opt-in and scoped.

CC only sees information that users choose to share. The same least-privilege principle should apply to business agents. An agent responsible for processing invoices should not automatically have access to HR documents.

Keep shared and personal memory separate.

CC separates household information from individual context. Business agents should do something similar. Company-wide information such as price lists and standard operating procedures can be shared broadly, while personal sales notes or private customer information should remain appropriately restricted.

These are practical design principles for any organization building agent-based systems.

4. Your Customers’ AI May Read Your Emails First

This is one of the changes businesses may overlook.

When AI agents start reading and organizing household email, your customer’s AI may process your message before the customer does.

That means businesses are increasingly writing emails for two audiences.

The first is the person receiving the email.

The second is the AI system helping that person organize their life.

This makes basic email structure more important.

Businesses should consider a few simple practices:

Put dates, times, and locations in plain text , rather than relying only on images or designed banners.
Attach calendar invitations (.ics) to appointments and events where appropriate.
Use fillable PDFs instead of scanned forms when customers need to complete documents.
Use clear subject lines , such as “Appointment confirmed: Tuesday, October 6 at 3:00 PM,” instead of vague subject lines.
Keep one main action per message whenever possible. It is easier for an AI agent to identify a task when the email has a clear purpose.

If your email is easy for an AI agent to understand, it has a better chance of becoming an actionable item in your customer’s workflow.

If the information is buried inside images, unclear subject lines, or long blocks of text, the agent may not be able to extract the right action.

5. IT Teams Should Plan for “Shadow Agents”

Consumer AI agents are becoming easier to use.

That also means employees may be tempted to forward work information to personal AI tools, especially when they are managing both personal and work schedules.

IT and security teams should address this before it becomes a problem.

Update acceptable-use policies

Company policies should clearly explain whether employees can forward company information to personal AI services and what types of information are prohibited.

Use DLP controls

Data loss prevention tools can help identify or block automatic forwarding of corporate information to external addresses and services.

Provide an approved alternative

Employees often use unofficial tools when the official tools do not solve their problems.

Providing an approved AI assistant with appropriate enterprise controls can reduce the temptation to move sensitive information into consumer AI products.

Frequently Asked Questions About Google CC

What is Google CC?

Google CC is an experimental AI agent from Google Labs that works as a shared assistant for families and households. It has its own verified Google account and turns what members share into a daily “Your Day Ahead” brief, calendar events, and a shared task list.

How many people can share one CC?

Up to six household members can share one CC. Each member must be 18 or older and use a personal Google account.

Can Google CC read my entire Gmail inbox?

No. CC only sees what each member chooses to share. Members can forward individual emails or files, auto-share messages from trusted senders, and approve new senders from a weekly list.

Who can use Google CC right now?

CC is available on web and mobile to adults in the U.S. with a personal Google account. Existing CC users receive an upgrade invitation by email, and new users can join the waitlist through Google Labs.

Can businesses use Google CC with Google Workspace accounts?

No. CC currently supports personal Google accounts only. Businesses can apply the same auto-forwarding and daily-brief patterns using Gemini in Google Workspace, Microsoft 365 Copilot, or automation platforms such as Zapier and Make, configured with business controls.

My Take

After years of watching family organizer apps launch and disappear, one thing stands out.

These products usually do not fail because they lack features.

They fail because someone still has to keep them updated. Most of the time, that person is the same person who was already responsible for keeping track of everything.

That is why the auto-CC model is the part of CC that I find most interesting.

Information reaches the agent from the places where it already arrives. Nobody has to enter the same information again into another application.

The technical design is also worth watching.

A separate identity, an isolated runtime, opt-in information sharing, and separate shared and individual memory are all useful ideas when building AI agents.

CC still has obvious limitations. It is currently limited to the U.S., requires personal Gmail accounts, excludes users under 18, does not support school-issued accounts, and has no announced pricing.

For business owners and IT teams, the takeaway is not to sign the company up for CC. That is not what the product is designed for.

The bigger takeaway is to watch how Google is building it.

CC is an interesting example of how AI agents can move beyond answering questions and start managing information and taking actions on a user’s behalf.

There is another change businesses should pay attention to.

Your customers’ AI systems are starting to become ** part of the interface between your business and your customers **.

That means internal AI agents need strong identity, isolation, permissions, and clear memory boundaries.

It also means customer communication needs to be structured in a way that both people and machines can understand.

If you’re the parent who always knows when picture day is, CC may be worth watching.

If you run a business or IT team, the architecture behind it may be even more interesting than the household features.

The post Google CC Wants to Be Your Family’s Chief of Staff. Here’s What It Does and What to Watch appeared first on 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..