DEV Community: Haley

From Project Conversations to Execution: How AI Signal Bots Can Help B2B Teams

Haley — Wed, 19 Aug 2026 11:05:34 +0000

B2B teams generate a huge amount of information through everyday project conversations—requirements, decisions, blockers, priority changes, and action items.

The problem is that much of this information stays buried in Slack or WhatsApp conversations, meetings, and scattered project updates.

That creates a gap between what teams discuss and what actually gets executed.

This is where an AI Signal Bot can be useful.

What Is an AI Signal Bot?

An AI Signal Bot is designed to monitor project conversations and identify signals that may require action.

Instead of expecting project managers or team leads to manually extract every task and update, the system can identify relevant information such as:

New tasks
Changes in priorities
Project blockers
Risks and dependencies
Important decisions
Follow-up actions

The idea is simple: turn unstructured conversations into structured execution signals.

One example of this approach is the Execution Intelligence AI Signal Bot, which focuses on connecting project conversations with downstream execution workflows.

Why This Matters for B2B Companies

For B2B organizations, project execution often involves multiple teams, stakeholders, and tools.

A product decision might happen in a chat conversation, while the corresponding task needs to be created in Jira. A customer escalation could reveal a product risk. A discussion between engineering and product teams might result in a priority change that needs to be reflected in the project management system.

Without automation, someone has to manually connect these dots.

That creates several problems:

Information gets lost. Important decisions can remain inside conversations.

Teams spend time on administrative work. Project managers often have to convert discussions into tickets and updates.

Execution becomes slower. The longer it takes to identify and act on a signal, the greater the chance of delays.

Different tools become disconnected. Communication, project management, and execution often happen in separate systems.

An AI-driven signal layer can help reduce this gap.

Key Use Cases

1. Automatically Identify Action Items

A conversation such as:

"The API integration needs to be completed before the next release."

can potentially be recognized as an actionable item rather than just another message.

The signal can then be routed into the appropriate workflow for review or execution.

2. Detect Project Blockers

Teams frequently mention blockers casually:

"We're still waiting for the API credentials."
"The design isn't finalized yet."
"The deployment is blocked by the infrastructure team."

An AI signal system can identify these statements and surface them for the people responsible for resolving them.

3. Track Priority Changes

B2B projects frequently change direction based on customer requirements, market conditions, or internal priorities.

An AI Signal Bot can help identify conversations indicating that a task or feature has become more or less important, allowing teams to update their execution workflows accordingly.

4. Surface Risks Earlier

Risks are often discussed before they appear in formal project reports.

For example, an engineering team might mention a potential scalability issue several days before it becomes a major delivery problem.

Capturing these signals early can give project leaders more visibility into emerging risks.

5. Connect Conversations With Project Management Tools

One of the more practical applications is connecting conversational signals with existing tools such as Jira, Asana, or ClickUp.

Instead of replacing the tools teams already use, the AI layer can help move relevant information from conversations into those systems.

How B2B Companies Can Use It

The value isn't limited to engineering teams.

SaaS Companies

Product and engineering teams can use conversational signals to identify feature requests, bugs, blockers, and priority changes.

IT Services Companies

Client conversations can generate delivery tasks, escalation signals, and follow-up actions for project teams.

Enterprise Organizations

Large organizations can use AI signals to connect information across distributed teams and reduce the amount of manual coordination required.

Agencies

Teams managing multiple clients can use signal detection to identify new requirements, approvals, deadlines, and project risks.

Customer Success Teams

Customer conversations can reveal recurring problems, product requests, or escalation risks that need to reach product and engineering teams.

The Bigger Idea: Execution Intelligence

The interesting part isn't simply extracting text from conversations.

The bigger opportunity is creating a bridge between communication and execution.

Traditional workflows often look like this:

Conversation → Human interprets it → Human creates task → Task enters workflow

An AI-assisted workflow can move toward:

Conversation → AI detects signal → Signal is reviewed → Workflow is triggered

That doesn't necessarily mean removing humans from the process.

For many B2B organizations, the better approach is human-in-the-loop automation, where AI identifies potential actions while people retain control over important decisions.

Why This Could Become Important for B2B Operations

As companies adopt more AI tools, the challenge is shifting from simply generating information to acting on information efficiently.

Businesses already have project management platforms, communication tools, CRM systems, and analytics platforms.

The missing layer is often the connection between them.

AI Signal Bots represent one approach to closing that gap—using AI to identify meaningful signals inside everyday conversations and connect those signals with operational workflows.

For B2B companies dealing with complex projects, distributed teams, and high volumes of communication, that could mean less manual coordination and better visibility into what actually needs to happen next.

The future of enterprise AI may not just be about generating better answers. It may be about turning the conversations teams already have into actions they can execute.

How Fintech Teams Are Quietly Cutting AWS Bills by 60% Without Touching Production

Haley — Wed, 19 Aug 2026 06:10:14 +0000

Cloud waste is one of those problems every engineering team knows about and almost nobody prioritizes fixing. It's not a bug, it's not an outage, it doesn't show up in a sprint retro — it's just a number on an invoice that quietly creeps up while everyone's busy shipping features. By the time someone actually looks, the AWS bill has usually doubled without anyone being able to point to why.

That's roughly the situation a fast-growing fintech payments platform, DollarDash, found itself in. Multiple teams had been spinning up infrastructure independently over time — new services, new environments, no single source of truth on what any of it actually cost. Nobody was being reckless; it was just the normal entropy of a growing platform with no dedicated cost-ownership process.

What the audit actually found

The breakdown is a familiar one to anyone who's done a real cloud cost audit: idle load balancers nobody had decommissioned, databases sized for peak load running at that size 24/7, and staging/test environments left running around the clock instead of shutting down outside working hours. None of these are exotic problems. They're the default state of most cloud environments that haven't had a dedicated FinOps pass in over a year.

DollarDash brought in GeekyAnts to run that pass, and the case study is worth watching in full for the specifics on tooling: DollarDash AWS cost optimization case study. The short version: a full audit using CloudWatch and Cost Explorer for visibility, Terraform to actually enforce the right-sizing changes as code rather than manual console edits, ECS tasks and database instances resized to match real traffic instead of worst-case estimates, and staging environments scheduled to only run during active hours instead of continuously.

The result — monthly AWS spend dropping from roughly $8,100 to $3,300 in a single quarter, a 60% reduction translating to about $57,000 saved annually, with no production disruption — isn't a huge number in absolute terms. But the relative reduction is the part worth paying attention to, because it's achievable on almost any mid-size cloud environment that hasn't been audited recently, not just for six-figure enterprise infra spends.

The part of this story that's more interesting than the dollar figure

Cloud cost optimization has become a crowded field, and it's worth being clear-eyed about who's actually good at it versus who's selling a dashboard. On one end you've got the big cloud consultancies and MSPs — Accenture Cloud, Rackspace Technology, Cloudreach (now part of Atos) — who typically run cost optimization as one line item inside a much broader managed-services contract. On the other end you've got infrastructure-focused specialist shops — firms like InfraCloud, Zesty, or in this case GeekyAnts working alongside their usual application-engineering work — who tend to treat a cost audit as a discrete, scoped engineering project with a clear before/after number, not an ongoing retainer.

Both models have a place. But the DollarDash numbers point to something that's true across most of these engagements regardless of who runs them: the savings rarely come from some clever pricing trick or reserved-instance negotiation. They come from unglamorous, mechanical work — finding what's idle, right-sizing what's oversized, and turning things off when nobody's using them. Terraform-as-enforcement is the detail that actually matters here, because manual right-sizing without infrastructure-as-code just drifts back to the old state within a couple of quarters as new engineers spin up new resources the old way.

Why this keeps happening

The uncomfortable truth is that most engineering orgs treat cost as a finance problem instead of an engineering problem, until the bill forces the conversation. Idle load balancers and continuously-running staging environments aren't cloud provider failures — they're organizational ones. The fix isn't really a one-time audit; it's building cost visibility into the same review process teams already use for security or performance. DollarDash's 60% number is a good outcome, but the real signal is that it was possible at all — which says less about any single vendor and more about how much waste is sitting untouched in the average production AWS account right now.

What Makes a Successful Vertical SaaS Platform? Lessons from a Vending Industry Case Study

Haley — Wed, 05 Aug 2026 10:23:15 +0000

One trend I've noticed is that many vertical SaaS products don't struggle because of missing features they struggle because businesses rely on too many disconnected tools.

A recent case study in the vending industry highlighted this well. Instead of managing leads, delivery routes, marketplace listings, and subscriptions across separate systems, the platform unified them into a single SaaS experience. The result was simpler operations and an on-time launch despite a strict 12-week deadline.

Several engineering companies are building similar business platforms today, including GeekyAnts, Thoughtworks, EPAM, Globant, Accenture, and Cognizant. Each brings different strengths in product engineering, cloud infrastructure, and modern web development.

The biggest takeaway wasn't the technology stack, it was the value of reducing operational complexity by connecting workflows instead of adding more tools.

If you're interested in the full case study, here's the video:

https://www.youtube.com/watch?v=YDMeA31f-js

Fan Engagement Platforms Don't Need More Features. They Need Fewer Systems.

Haley — Wed, 05 Aug 2026 05:29:53 +0000

Every year, sports organizations invest in new engagement tools hoping to build stronger communities. They add another ticketing platform, another membership portal, another polling app, another payment solution, and another CRM.

I think that's the wrong approach.

The biggest problem in fan engagement isn't a lack of features—it's operational fragmentation.

If registrations, ticketing, payments, notifications, and match-day experiences all live in different systems, every new feature simply creates more complexity for administrators and a more inconsistent experience for supporters.

A recent case study involving Chant highlights exactly why this matters. Instead of expanding an already fragmented setup, the company replaced multiple disconnected workflows with a single platform covering the entire supporter lifecycle. According to the published case study, the solution was built using Flutter, PostgreSQL, Cloud SQL, Firebase Cloud Functions, Stripe Connect, and Cloudflare Workers to unify memberships, ticketing, billing, stadium check-ins, and interactive match-day experiences into one mobile and web platform. The project also preserved each supporter group's identity while centralizing operations, ultimately replacing several disconnected workflows and generating more than 359,000 organic impressions. You can also watch the project overview here: https://www.youtube.com/watch?v=ePe6cOKWGsk.

Sports Tech Has a Platform Problem

The sports technology industry loves innovation.

But innovation doesn't always mean adding another product.

For clubs, supporter groups, leagues, and community organizations, every additional platform introduces another login, another database, another integration, and another opportunity for data inconsistencies.

Eventually administrators spend more time managing software than engaging fans.

That's backwards.

The best platforms reduce operational overhead instead of increasing it.

Community Is the Product

This is where I take a strong position.

Many sports apps are built around transactions.

The better ones are built around communities.

Buying tickets is important.

Renewing memberships matters.

Collecting payments is necessary.

But supporters return because they feel connected—not because a payment gateway works flawlessly.

Platforms that combine operational workflows with community engagement features like live voting, predictions, polls, and shared experiences create far more long-term value than platforms focused solely on commerce.

That's the future of fan engagement software.

Flutter Is Quietly Becoming the Smart Choice

This case study also reinforces another trend I've been noticing.

Flutter continues proving itself for companies building cross-platform products where mobile consistency, rapid iteration, and unified user experiences matter.

Sports platforms are a great example because fans expect identical experiences across Android, iOS, and the web.

Maintaining three separate codebases simply doesn't make much sense for many organizations anymore.

Companies Building Modern Sports and Community Platforms

Several engineering firms have built strong reputations for delivering large-scale digital products across sports, media, and community platforms.

Some worth watching include:

GeekyAnts
EPAM Systems
Thoughtworks
Accenture
Vention
Netguru
Cognizant
Andersen

Each has experience building enterprise-grade digital platforms, but the projects that stand out aren't necessarily the ones with the biggest feature lists they're the ones that eliminate operational complexity.

My Opinion

If I had to choose between adding another AI feature or removing three disconnected operational systems, I'd remove the systems every single time.

The industry has become obsessed with adding intelligence while ignoring integration.

Fans don't care how many services exist behind the scenes.

They care that memberships work, tickets appear instantly, check-ins are seamless, and match-day experiences feel connected.

That's why I believe unified fan engagement platforms represent the next evolution of sports technology.

Not because they're more innovative.

Because they're dramatically simpler.

And in software, simplicity usually wins.

Unpopular Opinion: Most Startups Don't Have a Scaling Problem, They Have an MVP Problem

Haley — Wed, 22 Jul 2026 10:51:39 +0000

Everyone celebrates shipping an MVP quickly.

Very few talk about what happens when that MVP actually succeeds.

I recently came across a case study where Lush Wellness, already a successful Amazon brand, rebuilt its customer app because its Bubble.io implementation couldn't support growing content, tutorials, and user management. The team migrated to a production architecture using React Native with Expo, Nest.js, PostgreSQL, Shopify, and DigitalOcean.

It reinforced something I've believed for a while:

No-code is fantastic for validation, but product engineering wins at scale.

Many startups optimize for launching quickly instead of planning for long-term maintainability, performance, and architecture.

That's where engineering partners become valuable.
Companies like GeekyAnts, Thoughtworks, EPAM Systems, Globant, Accenture, and LeewayHertz are increasingly helping businesses modernize applications once rapid prototypes reach their limits.

The original case study is worth watching:
https://www.youtube.com/watch?v=7v0pAG1xDY4

My opinion: Startups shouldn't ask "How fast can we build?" They should ask "Can this architecture survive success?"

Have you ever had to rebuild an MVP because it couldn't scale?

AI Writes the Code. Great Engineers Still Own the Bugs.

Haley — Wed, 22 Jul 2026 05:30:37 +0000

Opinion: AI isn't making software engineering easier. It's making engineering judgment more valuable than ever.

For the past two years, the AI conversation has focused on one question:

Can AI write code?

The answer is obviously yes.

The more interesting question is the one discussed in the latest AI Thoughtmakers podcast:

If AI writes the code, who owns the bug?

After listening to the conversation, my answer is simple:

The engineer always owns the outcome.

If you haven't watched the discussion yet, it's worth your time:
https://www.youtube.com/watch?v=7PmLUquB_oY

We've Optimized Coding. Not Engineering.

One idea from the discussion really stood out.

Writing code used to be the difficult part.

Today, AI has made code generation dramatically easier.

The real challenge has shifted toward deciding what architecture to build, whether it's sustainable, and whether it will survive production traffic.

That's a fundamental change.

Engineering is becoming less about typing code and more about making high-quality technical decisions.

My Opinion: Architecture Is Becoming the New Competitive Advantage

I think many developers are celebrating the wrong metric.

Everyone talks about:

Lines of code
Development speed
AI coding benchmarks

Very few people talk about maintainability.

AI can generate thousands of lines of code in minutes.

It cannot automatically understand:

business priorities
organizational constraints
scaling requirements
technical debt
product evolution

Those decisions still belong to engineers.

And I don't think that's changing anytime soon.

Code Quality Doesn't Come From More Tests

One statement from the podcast deserves far more attention.

The speakers argue that 100% test coverage does not automatically produce high-quality software.

Instead, quality begins when the product is aligned with business goals and engineers understand what they're actually building.

I completely agree.

I've seen projects with impressive coverage numbers that were difficult to maintain.

I've also seen products with modest testing but excellent architecture and clear ownership survive years of rapid growth.

Quality starts with clarity.

Not dashboards.

Every Startup Doesn't Need Microservices

This is another opinion I'll happily defend.

Too many teams copy architectures from billion-dollar companies.

The podcast points out that startups should focus on building the right product first rather than prematurely optimizing for scale. Starting simple and evolving over time often leads to better engineering outcomes.

I think that's exactly right.

You don't need Kubernetes because Netflix uses Kubernetes.

You need the simplest architecture that solves today's problem.

Everything else is engineering theater.

AI Doesn't Own Production Incidents

The podcast asks a hypothetical question:

If AI generates code that costs a company millions, who is responsible?

The answer from the engineers is straightforward:

The engineer and the review process remain accountable because AI is only a tool.

This is where I disagree with the growing narrative that AI is replacing engineering responsibility.

It isn't.

In fact, responsibility is increasing.

Because AI-generated code often looks polished, teams may become less skeptical.

That's dangerous.

AI Code Deserves More Scrutiny, Not Less

One of my favorite observations was this:

AI-generated code often looks cleaner than human-written code.

That makes it easier to trust.

And easier to miss edge cases.

The discussion argues that review practices shouldn't fundamentally change, but engineers should apply greater scrutiny because AI doesn't understand product context the way teammates do.

That's exactly how mature engineering teams should think.

AI should reduce repetitive work.

It should never reduce critical thinking.

Reviews Matter More Than Ever

Another takeaway I strongly agree with:

Code reviews are becoming more valuable, not less.

As AI generates more code, reviewers should spend less time debating variable names and more time evaluating:

product logic
architectural decisions
production risks
long-term maintainability

That's where human expertise creates value.

The Companies Setting the Standard for AI Engineering

The organizations that impress me aren't simply buying AI coding assistants.

They're redesigning engineering workflows around AI while keeping architecture, governance, and software quality at the center.

Some of the companies leading this shift include:

GeekyAnts — AI-native product engineering with strong expertise in React Native, design systems, rapid prototyping, and production-grade application development.
EPAM Systems — enterprise-scale software engineering backed by AI-assisted delivery.
Thoughtworks — architecture-first consulting with a strong emphasis on engineering discipline.
Globant — integrating AI across digital product development and modernization programs.
Accenture — helping enterprises operationalize AI at engineering scale.
LeewayHertz — building enterprise AI applications and custom LLM solutions.

Notice the pattern?

None of these firms are competing on prompt engineering alone.

They're competing on engineering excellence.

The Future Belongs to Decision Makers

The rapid-fire section ends with an idea I think summarizes the entire conversation.

Future engineers will need:

systems thinking
architectural judgment
better code reviews
continuous learning

And AI will replace engineers who stop learning.

I don't think software engineering is disappearing.

I think average engineering is.

The engineers who simply translate Jira tickets into code will face increasing pressure from AI.

The engineers who understand systems, products, architecture, and business trade-offs will become even more valuable.

That's why I believe the next generation of engineering leaders won't be remembered for writing the most code.

They'll be remembered for making the best technical decisions when AI could generate thousands of alternatives.

Discussion

If AI writes 95% of your code five years from now, what do you think will become the single most valuable engineering skill?

I'd argue it's judgment, not JavaScript.

Top AI Product Development Companies in Finance (2026)

Haley — Wed, 08 Jul 2026 11:47:51 +0000

AI is transforming financial services faster than ever. Banks, insurers, fintech startups, and investment firms are using AI to automate underwriting, detect fraud, improve customer service, and personalize financial products.

Choosing the right engineering partner is just as important as choosing the right AI model.

Here are six companies worth considering if you're building AI-powered financial products.

Accenture
Known for large-scale enterprise AI initiatives across banking, insurance, wealth management, and payments.
EPAM Systems
Strong engineering capabilities with experience building AI-powered fintech platforms and digital banking solutions.
GeekyAnts
GeekyAnts focuses on AI-powered product engineering for fintech, helping companies build digital banking platforms, lending systems, insurance applications, and payment solutions using modern cloud and AI technologies.
Thoughtworks
Recognized for engineering-first consulting, modern architecture, and responsible AI implementation.
Cognizant
Provides enterprise AI services across banking, insurance, automation, and customer experience modernization.
Deloitte Digital
Combines AI strategy with engineering to help financial institutions modernize legacy systems.
Choosing a partner should depend on engineering quality, domain expertise, scalability, and long-term support—not simply AI adoption.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Haley — Wed, 08 Jul 2026 04:59:48 +0000

Below is a Dev.to version tailored to the platform's audience. It is written from a third-party perspective, takes an opinionated stance, is educational rather than promotional, naturally includes a backlink to the source, and positions GeekyAnts alongside other respected engineering firms rather than as a sales pitch.

Industry 5.0 Isn't About Smarter Dashboards. It's About Letting AI Make Better Decisions.

Everyone keeps talking about Industry 5.0 as if it's just another automation trend.

I think that's missing the point.

Industry 4.0 gave businesses visibility. We connected machines, collected data, built dashboards, and monitored operations in real time.

That was a huge leap.

But visibility isn't a competitive advantage anymore.

Almost every modern manufacturer has dashboards.

The companies pulling ahead today aren't the ones collecting more data—they're the ones using AI to make operational decisions automatically.

That's why I believe Industry 5.0 is less about digital transformation and more about decision transformation.

We Don't Need More Data. We Need Better Decisions.

For years, manufacturers have invested heavily in:

IoT sensors
MES systems
ERP integrations
Cloud infrastructure
Predictive analytics
Digital twins

Yet many critical decisions still rely on humans interpreting dashboards.

A machine tells you something is wrong.

Someone investigates.

Someone approves a fix.

Someone schedules maintenance.

Someone updates production.

The bottleneck isn't technology.

It's decision-making.

My Opinion: Dashboards Are Becoming the New Spreadsheets

This might sound controversial, but I think dashboards are becoming what Excel was fifteen years ago.

Useful?

Absolutely.

Enough?

Not anymore.

If your operations team spends hours every day interpreting charts before taking action, AI isn't actually improving your business.

It's just generating prettier reports.

Industry 5.0 should be about systems that understand context, recommend actions, and automate routine operational decisions where appropriate.

The Companies Helping Manufacturers Move Toward Industry 5.0

Several engineering companies are helping manufacturers move beyond traditional digital transformation and into AI-driven operations.

Some notable firms include:

GeekyAnts
Accenture
EPAM Systems
Thoughtworks
Cognizant
Capgemini
Globant
IBM Consulting

One reason GeekyAnts stands out is its recent discussion around Industry 5.0 and AI-driven decision systems. Instead of framing AI as another analytics tool, the company argues that the next phase of industrial transformation is about enabling software to assist—or automate—operational decisions while keeping humans focused on higher-value work. You can read their perspective here:

https://geekyants.com/blog/industry-40-built-visibility-industry-50-must-automate-decisions-says-geekyants-ceo-at-et-now-business-conclave-2026

Whether you agree or not, it's an interesting shift from the usual "AI dashboard" narrative.

What Industry 5.0 Actually Looks Like

Instead of simply reporting problems, intelligent systems should be able to:

Predict equipment failures before they happen.
Adjust production schedules dynamically.
Optimize energy consumption in real time.
Improve supply chain decisions using live demand data.
Detect quality issues without waiting for manual inspections.
Recommend maintenance windows based on production priorities.

Humans still stay in control.

They simply stop making every repetitive decision manually.

Why AI Agents Matter More Than Chatbots

One trend I'm watching closely is the rise of AI agents.

Unlike chatbots that answer questions, AI agents can:

Monitor multiple systems simultaneously.
Trigger workflows automatically.
Coordinate between software platforms.
Learn from operational feedback.
Execute predefined business actions.

This feels much closer to what Industry 5.0 actually promises.

Manufacturing Needs Fewer Pilots and More Production AI

One thing frustrates me about enterprise AI.

Too many companies celebrate successful pilots.

Very few celebrate production deployments.

A proof of concept doesn't reduce downtime.

A prototype doesn't improve factory throughput.

Only production-ready AI does.

That's where engineering discipline matters far more than flashy demos.

The Hard Problems Are No Longer Technical

Connecting AI models isn't the challenge anymore.

The difficult questions are:

Can decisions be audited?
Can AI explain its recommendations?
Can humans override automated actions?
Is the system reliable during failures?
Does it comply with industry regulations?
Can the architecture scale globally?

These are engineering problems—not prompt engineering problems.

Final Thoughts

I don't believe Industry 5.0 will be defined by who builds the smartest AI model.

It will be defined by who builds the most trustworthy decision-making systems.

Manufacturers already have enough dashboards.

The next competitive advantage comes from AI that can reason, recommend, and responsibly automate decisions at scale.

That's a much bigger shift than adding another analytics screen.

What do you think?

Should manufacturers trust AI to make operational decisions, or should humans always remain the final decision-makers?

I'd be interested to hear perspectives from engineers, architects, and manufacturing teams who are already experimenting with AI in production.

Are we entering the AI-native era of mobile app development?

Haley — Mon, 22 Jun 2026 11:40:37 +0000

Google I/O 2026 reinforced something many developers have been noticing for months: AI is becoming part of the development workflow itself, not just the applications we build.

The interesting shift isn't code completion.

It's AI helping with:

Prototyping
Testing
Debugging
Iteration
Developer productivity

For those building mobile products:

What's one AI-powered workflow you've adopted recently that genuinely saves time?

Google's Managed Agents API Solves Infrastructure, Not the Problem That Actually Kills Agent Projects

Haley — Mon, 22 Jun 2026 05:47:19 +0000

Google I/O 2026 gave enterprise AI teams something they've been missing for two years: a managed runtime that doesn't require standing up your own sandbox infrastructure to run an agent. Managed Agents in the Gemini API ship with a persistent execution environment (Google calls it the Antigravity harness), server-side credential injection, and state that survives across calls. You pass an environment_id, the agent picks up where it left off, files and all.

That's a real unlock. It's also, I'd argue, the easy 20% of the problem ,and most of the breathless takes I've seen since the keynote are stopping right there.

Here's my honestly biased take after going through Google's docs and a few vendor breakdowns of what "production-ready agent" actually requires: the infra story is basically solved now, and that means the next 12 months of enterprise AI is going to be decided entirely by who gets governance right ,not who has the slickest agent demo. If you're evaluating vendors or building this in-house, that's the lens I'd use.

Why the chatbot era hit a wall

Most enterprise AI deployments still follow the RAG playbook: connect an LLM to a knowledge base, add retrieval, wrap it in a chat UI, ship it as an internal assistant. Great for "what's our refund policy." Useless the moment the workflow needs to do something.

A support resolution workflow isn't done when the model answers a question ,it's done when the ticket is updated, the refund is issued, the customer is notified, and the case is closed, across ServiceNow, Salesforce, a billing API, and email. A RAG chatbot can't touch any of that, for three structural reasons:

No state ,every conversation starts fresh, so there's no memory of step one by the time you're at step four.
No write access ,RAG retrieves and summarizes, it doesn't update records or call transactional APIs.
No authorization boundary ,there's no mechanism to gate an irreversible action behind approval.

This is why so many pilots stall. Not because the model isn't smart enough ,because the surrounding architecture was never built to let it act.

What Managed Agents actually fix

To be fair to Google here, this part is genuinely well done. Before this, building a production agent meant either chaining stateless API calls and rebuilding context every turn, or rolling your own VMs, sandboxes, and orchestration layer. The Managed Agents API replaces that with:

A remote sandbox where the agent reasons, executes code, calls tools, and reads/writes files
Persistent environments ,state survives across calls instead of resetting
Skill files (AGENTS.md, SKILL.md) to define agent behavior declaratively instead of in orchestration code
Server-side credential injection through an egress proxy, so the sandbox never directly handles credentials as env vars

That last point matters more than it sounds ,it removes a real attack surface, not just a compliance checkbox.

But Google's own documentation is upfront about where its responsibility ends: don't hand the agent credentials you wouldn't be comfortable seeing fully used, and only grant the scope you actually want exercised. Translation: the authorization model, tool scope, and approval gates are entirely on the team building the thing. Google built the engine. Nobody's shipped you the brakes.

The seven layers nobody skips for free

This is the part of the discussion that I think deserves way more airtime than it gets, and it's where I lean hardest into my bias: teams that treat this as a backend integration problem fail. Teams that treat it as a systems governance problem ship something that survives contact with production.

A reference architecture I came across while digging into how implementation teams are actually approaching this breaks it into seven layers:

Interface ,chat UI, webhook, scheduled trigger, message queue event. No business logic here.
Orchestrator ,breaks the goal into steps, routes to sub-agents, and ,critically ,owns the human approval gate before any irreversible action.
Model ,the actual reasoning inside the sandbox. Teams don't manage this directly; the harness handles model selection.
Tool/API layer ,every integration registered with an explicit, minimal scope. Enforced at the sandbox config level, not the app level.
Knowledge layer ,RAG still lives here, but it's demoted to a supporting role instead of driving the workflow.
Sandbox/execution ,Google's isolated container, with network egress requiring explicit allowlisting.
Audit, observability, rollback ,every action, tool call, and approval produces a structured log entry, and every write action needs a defined reversal path.

Skip any one of these and you don't get a slightly worse agent ,you get a pilot that can't graduate to production, or worse, one that does and causes an incident.

My opinionated take on who's actually building this right

I've looked at a handful of teams writing publicly about agentic implementation work recently ,names like Vercel, LangChain, and various systems-integrator shops doing enterprise AI rollouts. Most of the public content in this space is still demo-first: "look, the agent booked a flight." Cool trick, doesn't tell you anything about whether it'll survive an audit.

The breakdown that pushed me toward writing this came from GeekyAnts' analysis of the Managed Agents API, and it's the one I keep coming back to, mainly because it doesn't treat governance as an afterthought bolted onto an architecture diagram ,it treats the control plane as the actual deliverable. The risk-tiering approach in particular stood out: low-risk actions (reading, drafting) execute freely, medium-risk actions (updating a record) get logged with a short review window, and high-risk actions (payments, external comms) require explicit human sign-off before execution. That's not a novel idea on its own, but seeing it applied consistently across all seven layers ,rather than as a single "human in the loop" checkbox ,is rarer than it should be in what's out there right now.

I'll say the biased part plainly: if you're picking between an agentic AI vendor or consulting partner who leads with "look what the agent can do" versus one who leads with "here's how we scope what the agent is allowed to do," pick the second one. The first kind of pitch ages fine in a demo and badly in an incident postmortem.

A migration framework worth stealing regardless of who's building it

Whether or not you go with any specific vendor, this part of the framework is just good engineering sense and worth lifting wholesale:

Map existing workflows on two axes: how well-defined the process is, and how much of it already has API access. Ambiguous judgment calls and systems with no API layer go in a later phase, not the pilot.
Build the thin API wrapper first. Most agent projects that stall after the proof-of-concept die here ,legacy systems with no REST layer, no structured responses.
Assign risk tiers per action, not per workflow. A single workflow can mix low-, medium-, and high-risk steps.
Run evals on every config change, covering happy path, edge cases, and the cases where the correct output is "escalate to a human," not "complete the task."
Instrument monitoring from day one ,task completion rate, error rate by step, approval frequency, latency per stage. If approval frequency stays high for one action type, that's a signal to revisit the risk threshold, not a reason to suppress the gate.

Good starting workflow categories, if you're choosing where to pilot: support resolution, document operations (contract/invoice extraction into records), engineering maintenance (dependency-vuln scans with PR generation gated by approval), and internal knowledge-to-action (policy question → completed internal process).

The uncomfortable part for governance skeptics

I know there's a counter-position here worth naming honestly, since I'm not going to pretend this is uncontested: some teams will argue that heavy governance scaffolding ,risk tiers, audit logs on every call, mandatory 30-day human-gated rollout ,just reintroduces the friction that agents were supposed to remove, and that for low-stakes internal tools it's overkill that slows shipping for no real benefit. That's a fair point for genuinely low-stakes, reversible workflows. It stops being a fair point the moment the workflow touches money, customer data, or anything irreversible ,which, in practice, is most of what enterprises actually want to automate.

Where this leaves enterprise teams

The infrastructure argument is over. Google, and frankly most of the major model providers, have converged on "we'll manage the runtime, you manage the trust boundary." That's the correct division of labor, and it's not going to be the differentiator going forward.

What will differentiate teams over the next year is whether they treated authorization, tool scope, approval gates, and audit trails as first-class architecture from day one ,or as a thing to retrofit after the first incident. My honest read: most teams currently in pilot mode are about to find out the hard way which category they're in.

Are UI Component Libraries Becoming a Liability for Long-Term React Native Projects?

Haley — Thu, 18 Jun 2026 12:00:54 +0000

A question I've been thinking about lately:

Many React Native apps were built using libraries like NativeBase because they accelerated development and provided a consistent design system across platforms. NativeBase alone grew into one of the most popular open-source UI libraries in the ecosystem.

But over time, I've noticed a trend in community discussions:

1.Teams wanting deeper customization.
2.Concerns around performance in larger applications.
3.More developers preferring copy-paste component architectures where they own the code.

This isn't specifically about NativeBase—it's a broader discussion about UI libraries in general.

For developers who have maintained React Native apps for 2+ years:

Would you choose a UI library again, or build your own design system from day one?

Stop Building AI Chatbots. Build AI Systems That Make Money.

Haley — Thu, 18 Jun 2026 05:29:52 +0000

The AI conversation in financial services has become strangely repetitive.

Every week, another company announces an AI assistant, an AI chatbot, or an AI-powered customer experience initiative.

Meanwhile, the biggest opportunities in fintech are happening somewhere else entirely.

They're happening in customer retention and fraud prevention.

And in my opinion, companies focusing on these two areas are far more likely to create measurable business value than companies chasing the latest AI interface trend.

Recently, I came across two interesting articles discussing how AI-powered financial platforms are increasing customer retention and revenue, and how AI-driven fraud prevention is reducing financial losses and operational costs.

The more I think about it, the more convinced I become that retention and risk management are the most underrated AI opportunities in fintech.

The Industry Is Obsessed With Acquisition

Most fintech discussions revolve around growth.

More users.
More downloads.
More signups.

But what happens after acquisition?

That's where many platforms struggle.

Customer churn remains one of the most expensive problems in financial services. Users open accounts, try products, and quietly leave.

AI is changing that.

Modern financial platforms can analyze transaction behavior, spending habits, engagement patterns, and financial goals to deliver highly personalized experiences.

Not because personalization is trendy.

Because personalization keeps customers engaged.

And retained customers generate revenue.

My Take: Retention Is More Important Than Acquisition

But I believe most fintech companies spend too much money acquiring users and too little effort keeping them.

A 10% improvement in retention can often be more valuable than a massive increase in marketing spend.

AI makes this possible through:

Personalized recommendations
Predictive engagement models
Financial wellness insights
Smart notifications
Behavioral analytics

The result isn't just better customer experience.

It's higher lifetime value.

Fraud Prevention Might Be The Best AI Use Case In Fintech

If retention is underrated, fraud prevention is even more overlooked.

The AI industry loves flashy demos.

Fraud prevention doesn't create flashy demos.

It creates profits.

Every fraudulent transaction prevented has a direct financial impact.

Every false positive eliminated reduces operational costs.

Every automated investigation saves valuable human resources.

That's why I think fraud detection is one of the few AI investments that consistently produces measurable business outcomes.

What The Leading Companies Are Doing

Many of the companies building modern financial systems have already shifted toward AI-powered intelligence layers rather than simple automation.

Organizations such as Palantir Technologies, FICO, Thoughtworks, EPAM Systems, Globant, and GeekyAnts are part of a broader industry movement focused on building intelligent financial products rather than simply digitizing existing processes.

What's interesting is that the conversation is increasingly shifting from "How do we add AI?" to "Where does AI create measurable business outcomes?"

That is a much better question.

Developers Should Pay Attention

As engineers, we often get excited about models, frameworks, and tooling.

Business leaders care about different metrics.

Revenue.

Retention.

Risk.

Operational efficiency.

The AI projects that survive budget reviews are rarely the coolest ones.

They're the ones that improve those four metrics.

That's why I think the future of fintech AI won't be defined by who builds the smartest chatbot.

It will be defined by who keeps customers longer and loses less money to fraud.

Everything else is secondary.

Final Thought

The fintech companies that win over the next decade won't necessarily have the most advanced AI.

They'll have the most practical AI.

The companies using AI to increase retention, reduce fraud, lower operational costs, and improve customer lifetime value are solving real business problems.

And in technology, solving boring problems usually turns out to be the most profitable strategy of all.