At DAIS 2026, Databricks announced Lakehouse//RT, powered by Reyden, a ground-up engine rewrite and not an update to Photon. It runs against existing Delta and Iceberg tables without restructuring, requires Unity Catalog, and keeps data in open formats. 

Databricks frames the value proposition around three costs of maintaining a separate serving layer: data duplication into proprietary storage, governance policies that don’t travel with the data out of Unity Catalog, and the ongoing engineering burden of owning a second pipeline. 

Official performance claims include up to 16x better performance versus real-time serving layers, with response times as low as 10 milliseconds on smaller datasets and sub-100 milliseconds on larger ones.

How We’re Using It 

A healthcare client came to us with a straightforward problem: their FHIR data was already in Databricks, and they didn’t want another system to manage it. Standing up a dedicated FHIR server (HAPI, Azure FHIR API, Smile CDR) means another deployment, another copy of PHI, another governance boundary, another bill, and another platform someone has to debug. The question was whether the lakehouse they already had could do the job. 

The system follows a three-layer pattern. Bronze handles raw ingestion and is never modified; it’s the source of truth, and its immutability is what makes compliance and audit defensible. Silver holds cleaned, validated data optimized for queries. The API layer, built on FastAPI, serves FHIR REST endpoints to consuming systems. Keeping these concerns separated means ingestion, processing, and serving don’t interfere with each other, and each layer scales independently. In a healthcare setting, that clean boundary between raw and transformed data is useful well beyond performance. 

DBIgnite feeds Bronze directly, pulling from EHRs and APIs or consuming pre-staged landing zones depending on the source system. 

The request flow: a FHIR client calls an endpoint → FastAPI validates and translates the FHIR parameters → the service layer generates optimized SQL → Databricks queries Bronze or Silver → results are mapped to the FHIR schema → a JSON response is returned. Each step is independently observable and testable. 

What We Built 

We explored storing raw FHIR resources in JSON, NDJSON, and Variant format directly in Delta tables. Unity Catalog handled governance. The problem was query performance: deeply nested FHIR JSON in a lakehouse doesn’t behave like a transactional FHIR server, and the gap on patient-specific lookups was real. 

To put numbers to it, we built a claims query system for Explanation of Benefit (EOB) records: what a patient’s plan covered, what was billed, how the claim was adjudicated. Runs on Databricks App, ingests via DBIgnite into Delta tables under Unity Catalog. Baseline performance using Databricks SQL: sub-300 milliseconds for search queries, sub-150 milliseconds for direct record retrieval. Workable, but not fast enough to feel invisible. 

What We Observed 

Patient-specific EOB lookups across a few billion records, each query returning 50–100 records scattered across all data files with no clean partition shortcut. 

On individual EOB lookups, DBSQL averaged approximately 550 milliseconds. Reyden on a small cluster averaged 86 milliseconds, roughly 84% lower latency. All seven of the seven individual EOB queries improved. Reyden’s ceiling (111 milliseconds) didn’t reach DBSQL’s floor (488 milliseconds). Scaling to a large cluster (4x the compute) produced no meaningful gain: 93 milliseconds versus 86 milliseconds, statistically indistinguishable. One collated EOB query pattern was slower on Reyden across all cluster sizes. One collated EOB query pattern was slower on Reyden across all cluster sizes. Query shape matters, and there are areas worth investigating for further optimization. 

DBSQL vs. Reyden Execution Times

Where This Leaves Us 

The case for consolidating FHIR services natively in Databricks is now a serious engineering conversation, not a wish list item.

Reyden delivered sub-100 millisecond patient-specific lookups across billions of records on a small cluster, without a separate serving layer, without a second copy of PHI, and without a second governance boundary to maintain. For healthcare teams already running on Databricks with Unity Catalog deployed, the path to retiring a third-party FHIR server or real-time serving layer is shorter than it has ever been. As Reyden moves toward general availability, we see a real opportunity to consolidate the full FHIR stack: ingestion, governance, and low-latency serving inside a single platform. We will be building on it. 

The post Exploring Lakehouse//RT and Reyden: Can Databricks Handle FHIR Data at Scale? appeared first on Perficient Blogs.

This isn’t primarily a technology problem. It’s a distance problem — between what data knows and what care teams can act on. It’s one of the clearest themes emerging from our conversations at this year’s Databricks Data + AI Summit.

The Industry Has Moved Past “AI Is Coming” 

The conversation has already shifted. Fewer organizations are asking whether to adopt AI. More are asking why it isn’t producing outcomes yet. 

This week shows that experimentation has given way to engineering: correctness, explainability, operational intelligence at the point of decision. The industry is entering its control era, where trust, context, and governance separate organizations that scale from those that stall. 

What’s striking is where many organizations actually are. Across the industry, organizations have made significant investments in modern data platforms, but adoption is still unfolding in pockets. The gap between investment and realized value is growing. The commitment is real, but the outcomes haven’t followed. 

Three Places the AI Gap Shows Up 

Three realities keep surfacing in conversations with health insurer executives this week: 

1. Technical: Connecting clinical record systems to modern analytics environments remains one of the most persistent barriers to a complete picture of each member. Interoperability mandates have pushed the industry toward better data sharing for years — but while the vision is clear on paper, the pipelines often aren’t.
2. Operational: The breakdown is most visible in quality performance programs. Metrics are tracked with precision, but that insight rarely reaches care teams early enough to change what happens next. The gap stays open not because the organization didn’t know about it, but because knowing something in a report is very different from having it surface for a care manager at the exact moment a decision needs to be made.
3. Cultural: Getting clinical and operational teams to trust AI outputs, change their workflows, and act on new signals requires organizational transformation, not just new software. Technology readiness is often ahead of people readiness, and that mismatch quietly stalls initiatives.

“Most health plans don’t fail because of bad models — they fail because insights don’t reach care managers in time.” — Priyal Priyal, Associate Vice President

What Closing the Gap Requires 

Two capabilities are needed here, and neither works well without the other. 

A governed, unified data foundation 

• Brings together claims, clinical, and social determinants of health data into a single trusted layer 

• Enables AI models to move from development to real-world use without losing the guardrails regulated industries require 

• Perficient’s Brickbuilder accelerators are designed to compress time-to-value on the Databricks platform, giving health insurers a faster path to that foundation without starting from scratch 

Operational expertise to connect data to care 

• Bridges the foundation to clinical workflow, care team behavior, and real change management 

• Systems can be governed and models can be deployed, but member outcomes don’t improve unless care manager workflows actually change 

• Healthcare expertise — built from years working with health insurer organizations on quality programs, care management operations, and clinical data integration — is what turns a deployment into a result rather than a proof of concept 

Perficient’s work with health insurer organizations sits at that intersection. The platform is a starting point. Producing outcomes that reach patients is the goal. 

Read more: Improve Healthcare Quality With Data & AI 

The Forcing Functions Are Here 

Federal interoperability requirements, prior authorization rules, and value-based care contracts are creating pressure that wasn’t there two years ago. For most health insurers, the question of whether to activate data and AI infrastructure is settled. The question is how fast, and with what. 

From everything we’re seeing at DAIS this week, one thing is clear: Healthcare AI isn’t broken — but the way it connects to real decisions still is. And until that connection is solved, no investment, no model, no platform will be enough.

The organizations that close that gap won’t just move faster. They’ll be the ones that actually deliver on the promise of AI in healthcare. That’s what this week at DAIS keeps coming back to. 

See where your organization is on the activation curve. Connect with Perficient’s Healthcare & Life Sciences team to explore our AI-first healthcare offerings and Brickbuilder accelerators on the Databricks platform or schedule a demo. 

The post Why AI Stalls for Health Plans: Turning Data Into Action appeared first on Perficient Blogs.

I opened my laptop to catch up on last week’s announcements and landed on Databricks’ release of Omnigent. 

A couple of hours, reliable WiFi, and a new open-source orchestration layer—good enough conditions to see what this could actually do in practice. 

As I reviewed the announcement and dug into the GitHub repo, I decided to test it in real time—using AI-assisted development (primarily Claude via CLI) as the interface for building and managing the setup. 

What Is Omnigent? 

Omnigent is an open-source multi-agent AI orchestration platform released by Databricks. 

At its simplest, it acts as a management layer on top of your existing AI development tools—Claude Code, OpenAI Agents SDK, Codex, and others. You’re not replacing your tools—you’re orchestrating them. 

For development teams, the value shows up in structure and scalability: 

• Persistent sessions with shared context 

• Worktree support for parallel development 

• A unified interface for managing multiple agents
   

Instead of fragmented workflows and one-off sessions, you get reproducibility, visibility, and a foundation teams can collaborate on. 

What’s notable here is the direction: Databricks isn’t just investing in data and AI infrastructure—they’re shaping how engineering teams build on top of it. Omnigent focuses on managing the workflows and agents themselves, not just the underlying data. 

Wall #1: Windows

First thing I noticed when I went to install, I’m on Windows. That’s wall number one. No time for an IT requisition for a MacBook Pro.

Omnigent runs cleanly on Linux/Mac. On Windows you’ve got a decision to make. Claude started to recommend patching Omnigent, a path I did not want to go down. It was built to run on Linux/Mac for a reason. The easiest answer: Windows Subsystem for Linux (WSL).

wsl --install

That’s honestly most of it. WSL 2 ships with Ubuntu by default. A restart, a few minutes, and I had a clean Linux environment to work in.

The Install: Actually Easy

Once inside WSL, the Omnigent install was one command:

pip install omnigent

No dependency drama, no version conflicts. The kind of install experience that makes you suspicious something is about to go wrong. Nothing did.

From there, a quick interactive setup gets you configured:

omnigent setup

The wizard walks you through choosing your harness (Claude SDK, OpenAI Agents SDK, or others), setting your endpoint, and wiring up your model. It writes a config to ~/.omnigent/config.yaml. Two steps — install, configure — and you’re ready to run.

Wall #2: The AI Gateway

Here’s the part that actually took time, and it’s worth understanding because you may hit it too.

At Perficient, we use PortKey as our AI gateway. An AI gateway sits between your agents and the underlying models — it handles routing, cost tracking, observability, and fallbacks. Practically speaking, it means we’re not hardwiring API keys and model names everywhere, and we have full visibility into what’s running and what it costs. Worth the extra config step.

When connecting Omnigent to a gateway, the main decision is how you want to serve your models. You’ve got three paths:

1. Direct to vendor — simplest setup, point straight at Anthropic or OpenAI. Good for getting started fast, less overhead, less visibility.
2.  AI gateway (PortKey, LiteLLM, and others) — adds a layer between your agents and the models. You get routing, cost tracking, fallbacks, and observability across providers. If your organization already has one of these in place, this is probably your path.
3. Databricks Model Serving — if you’re already on Databricks, this is worth a look. You serve models through the same platform you’re already using, with Unity Catalog governance and the observability stack you’ve already got. For data and ML teams living in Databricks, it’s the most natural fit — one less integration to manage.

Once the right endpoint and model identifier were in, the config clicked into place:

providers:
  your-gateway:
    kind: gateway
    default: true
    anthropic:
      base_url: <your-gateway-url>
      api_key_ref: keychain:<your-key-ref>
      models:
        default: <your-model-identifier>

The structure is the same regardless of which path you take — the endpoint and model identifier are the two values that change. Know your serving layer before you sit down to configure.

Hello World

Once the config was dialed in, I ran the thing.

Typed a message. Got a response.

Hello World. 

There’s something about seeing your own agent stack respond — properly routed through your own gateway, with session context, in a clean environment, that makes the setup feel real. It’s a green light.

What’s Next

From Hello World, I started pulling in some of the in-flight work I’m already running — my to-do list, accelerators for our teams, demo scaffolding. That’s the actual test: not toy prompts, but real development work.

The next step I’m most interested in: building Databricks apps with this. Not just using Omnigent as a session manager, but running real development workflows, multiple agents across multiple worktrees, working in parallel on the same codebase. Our teams at Perficient are going to put this through its paces properly in the coming weeks.

That’s the bigger picture here. Databricks isn’t just extending the data platform, they’re extending how engineering teams work on top of it. Omnigent is a sign of where this is going: not just better data infrastructure, but better tooling for the people building on it. More to come once we’ve stress-tested it for real.

The Real Takeaway

• WSL is fast, clean, and the right call.
• An AI gateway is worth the extra step. If your organization doesn’t have one — look at PortKey. Routing, visibility, and cost control matter at scale.
• Know your serving layer. Direct to vendor, AI gateway, or Databricks Model Serving — each has different tradeoffs. If you’re already on Databricks, start there.
• Hello World matters. Don’t skip it. A clean green light before you start real work is worth 5 minutes.
• Do it on a plane. Forced focus, no meetings. Highly recommend.

Find Perficient at DAIS 2026

If you’re at Databricks Data and AI Summit, come find me. I’m happy to talk Omnigent, what we’re building at Perficient on top of Databricks, or how to get your own setup running.

The post Hello World at 30,000 Feet: Setting Up Omnigent En Route to DAIS 2026 appeared first on Perficient Blogs.

But speed has come with a side effect. 

Many organizations are discovering that while their interfaces look polished and their feature sets grow quickly, the underlying systems are becoming harder for users to understand. Navigation fragments, workflows become inconsistent, and teams spend increasing time fixing usability issues one screen at a time. 

The problem often isn’t the interface. It’s the structure underneath it. 

As AI-driven capabilities become embedded across digital products, restoring that structural layer of experience design is becoming increasingly important. 

The Layers of Modern Experience Design 

When organizations talk about digital experience, several related disciplines tend to get grouped together. 

User Experience (UX) focuses on how people interact with a system to accomplish tasks. 

Customer Experience (CX) focuses on the broader relationship between people and an organization across touchpoints and time. 

But there is another layer that often receives less attention: Experience architecture. 

Experience architecture shapes how information, workflows, and capabilities are organized so that UX and CX can function coherently across a product ecosystem. 

These disciplines operate at different levels: 

• UX designs interaction 

• CX designs relationship 

• Experience architecture structures the system 

When the architectural layer is strong, usability improvements scale across the entire product. When its weak, teams end up repeatedly redesigning individual screens while deeper problems persist. 

When Structure Disappears 

Many digital teams today operate under strong pressures: faster release cycles, data-driven decision-making, and constant feature expansion. 

These pressures bring clear advantages, but they also shift attention toward what is easiest to deliver and measure. 

The visible surface of products—the UI—often becomes the center of design work. 

Over time, deeper structural questions receive less attention: 

• How information is organized 

• How workflows connect across systems 

• Whether interaction patterns remain consistent 

• Whether the system matches how users actually think and work 

When this happens, organizations begin to see familiar symptoms: 

• fragmented navigation 

• inconsistent interaction patterns 

• growing design debt 

• increasing user confusion 

Many of these problems are not cosmetic. They are architectural. 

A Lesson from Human Factors 

UX originally emerged from disciplines such as human factors and ergonomics, which studied how people interact with tools in real-world environments. 

One well-known example comes from aviation during World War II. 

Pilots were accidentally raising landing gear instead of flaps during landing. The controls were identical in shape and located close together. 

Human-factors researcher Alphonse Chapanis redesigned the controls so they could be distinguished by touch. The errors disappeared. 

The pilots hadn’t been the problem. The interface had. 

The same lesson still applies to digital systems today: Many “user errors” are actually structural design errors. 

Why Architecture Matters Even More with AI 

The rise of AI-driven systems adds a new level of complexity to digital experiences. 

Traditional software typically presents fixed options and predictable outcomes. AI systems behave differently. They generate responses dynamically and adapt to user behavior. 

This changes the UX challenge. The central problem is no longer just interface design. It is intelligibility. 

Users need to understand: 

• what a system is capable of 

• where its boundaries lie 

• how their actions influence its behavior 

Without that clarity, AI systems can appear unpredictable or opaque. 

Experience architecture plays a critical role here because it structures: 

• how AI capabilities are presented 

• how feedback is communicated 

• how users maintain orientation and control 

In other words, architecture helps ensure that intelligent systems remain understandable to the people who rely on them. 

The Role of UX Architecture 

UX architecture refers to the structural layer of experience design that determines how a system works from the user’s perspective. 

It includes elements such as: 

• information architecture 

• navigation structures 

• task flows 

• interaction models 

• content hierarchy 

• alignment with user mental models 

This architectural perspective does not replace classic usability principles. Instead, it creates structural conditions that allow those principles to scale across complex systems. 

A simple way to think about it is: 

UI expresses usability. 

UX architecture enables usability. 

Just as software architecture precedes code, UX architecture precedes interface design. 

Designing for Long-Term Trust 

Digital systems operate within relationships of trust. When products become confusing, manipulative, or opaque, short-term metrics may improve—but long-term outcomes often decline. 

Customers abandon products. Support costs rise. Regulatory attention increases. 

Clarity and transparency are therefore not just design ideals. They are long-term business assets. 

Organizations that succeed with complex digital systems often invest in capabilities that reinforce architectural thinking, including: 

• systems mapping 

• design research 

• information architecture 

• interaction design 

• design systems and governance 

These capabilities help ensure that digital ecosystems remain coherent as they grow. 

Closing the AI Value Gap 

Many organizations today are investing heavily in AI capabilities but struggling to translate those capabilities into meaningful user outcomes. 

One reason is structural. 

AI features are often layered onto systems that were not designed to accommodate them. Without strong experience architecture, even powerful AI capabilities can feel confusing or disconnected from the workflows people actually need. 

Closing the AI value gap requires more than adding intelligence to systems. 

It requires designing systems so that people can understand, trust, and effectively use that intelligence. 

Looking Ahead 

The fragmentation of UX, CX, and product disciplines did not occur by accident. It emerged from real market pressures and technological change. 

But as digital ecosystems grow more complex—and as AI becomes embedded across products and services—many organizations are rediscovering a simple truth: 

Interfaces alone cannot sustain coherent experiences. 

What enables durable digital systems is architecture—both technical and experiential. 

When experience architecture provides that foundation: 

• UX can support effective interaction 

• CX can guide long-term relationships 

• product teams can balance business goals and user needs 

And organizations gain systems that remain understandable and resilient as they scale. 

The post Why Experience Architecture Is Critical for AI-Powered Digital Products appeared first on Perficient Blogs.

That’s where most strategies hit their limits. Not at the pilot stage, and not for lack of ambition. Because deploying AI and governing it are two different problems — and only one of them has been getting the attention it deserves.

Organizations Are Scaling AI Faster Than They’re Governing It

AI fluency is growing quickly across the enterprise. Leaders aren’t asking for basic introductions anymore. Instead, they’re asking where to apply AI, how to scale it, and whether they can trust what they’ve built.

At the same time, a gap is starting to emerge. Widespread experimentation hasn’t translated into real scale—nearly two-thirds of organizations still haven’t deployed AI across the enterprise. What works in a pilot doesn’t always hold up in production. What works in isolation often creates real complexity once teams embed it into daily operations. So, while moving fast is valuable, it only works when the right foundation is in place to support it.

Deployed Isn’t the Same as Governed

There’s a belief that shows up in many AI conversations, often without being stated directly: once AI is deployed, it’s been operationalized.

In practice, that’s where strategies can run into trouble. AI creates lasting value when organizations embed it inside systems that define its role, validate its outputs, and measure its performance over time. Without that structure, it’s difficult to scale with confidence.

That dynamic was visible at Appian World 2026. In fact, organizations made the most progress when they built AI directly into business processes—not when they ran it alongside them.

That’s what’s shaping the next phase of intelligent automation.

Governance Is What Separates Experimentation from Operational Performance

If there’s one thing many organizations are still working through, it’s not what AI can do — it’s what it takes to govern it at scale.

Governance determines where organizations use AI, what it can do, how teams validate its outputs, and how they measure performance over time. As agentic AI enters the picture, that structure becomes even more important.

The potential of agentic systems is real: taking action, coordinating across workflows, and operating with increasing autonomy. That same autonomy, without clear boundaries, introduces risk. Reliability doesn’t come from the model itself — it comes from the processes and safeguards built around it.

In practice, well-governed AI looks like this:

• Teams embed AI directly into workflows with clearly defined roles
• Inputs and expected outputs are specified upfront
• Outputs are validated within the process before action is taken
• Performance is continuously monitored and refined

“Agentic AI is exciting…but it’s still unproven and can’t fully be trusted. Governing it in a controlled set of use cases is critical to establishing trust and measuring the impacts.”- Craig Peterson, Director

The organizations seeing the strongest results aren’t trying to scale everything at once. Instead, they start with use cases they can measure, manage for risk, and prove in practice—then build from there.

At this stage, progress is less about how much AI you deploy and more about what you can run reliably and stand behind.

What Governed AI Looks Like in a Real-World Environment

Healthcare is one of the clearest examples of why governance matters — and it’s what we’ve seen in practice.

Our AI Healthcare Concierge helps patients and members navigate care, handling benefits questions, prior authorizations, referrals, and coordination across voice and chat. What makes it effective in a high-stakes environment is how it operates within a governed system:

• It handles specific, repeatable tasks rather than open-ended decisions
• Outputs feed directly into validated workflows before any action is taken
• Every interaction is measurable from the start
• Oversight is built into the process

While healthcare makes the stakes clear, the underlying principle applies broadly: AI is only as effective as the system it operates within. That’s the approach behind our AI Healthcare Concierge. Governed by design. Built to perform.

Scaling What You Can Govern Is the Competitive Advantage

That apprach is reflected in our work every day. As a result, Perficient won Appian’s Delivery Excellence Award for the third year in a row because we build solutions designed to hold up in real-world operations.

The organizations making the most progress aren’t necessarily deploying the most AI. They’re being deliberate about where they deploy it — and scaling only what they can govern.

That’s the difference between running experiments and building real advantage. The question isn’t just what’s possible. It’s what you can govern and prove is working.

Ready to move from AI experiments to AI you can stand behind? Contact us to discuss what governed AI looks like in your organization.

The post What Leading Enterprises Know About Governing AI at Scale appeared first on Perficient Blogs.

The Summit drew more than 20,000 attendees and shipped 26+ new capabilities across more than 500 sessions. CEO Sridhar Ramaswamy shared the keynote stage with Anthropic President Daniela Amodei — a pairing that, on its own, tells you where the center of gravity has moved. The headline wasn’t a faster warehouse or a cheaper query. It was a thesis: AI agents are only as useful as the governed data, semantic context, and verified identity standing behind them. 

If you couldn’t make it — or, like me, you were there and are still untangling the firehose — here are the six takeaways I keep coming back to, and what I think they mean for the teams I work with. 

1. The pitch changed: from data platform to control plane 

For years, Snowflake’s story was simple: bring your data, run your queries, pay for what you use. At Summit 2026, that story grew. The company reframed the AI Data Cloud as the operating system — the control plane — for an enterprise run by autonomous agents. 

That isn’t just marketing. The narrative arc on the keynote stage walked through three eras: the age of IT, the age of BI, and now the age of AI agents. The implication is sharp. If agents are going to act on your business — querying data, writing code, triggering workflows — then the platform that holds the data also has to govern the agents. Snowflake is making a bid to be that layer, not just the storage underneath it. 

2. Agents got names, surfaces, and a place to work 

Two rebrands anchored the agent story. Snowflake Intelligence became CoWork, a personal AI agent for knowledge workers, now reachable from an iOS app, a Slackbot, and — the one that made the room laugh — a Microsoft Excel extension. Cortex Code became CoCo, elevated from a coding assistant into a full autonomous development agent. 

CoCo is the more striking of the two. It now runs as a native desktop app for Windows and macOS, plugs into VS Code, and connects to Anthropic’s Claude Code so developers can route Snowflake-specific work from the tools they already live in. More importantly, it gained real autonomy: Automations run recurring tasks on a schedule, and Cloud Agents are serverless, event-driven workers that react to data changes — alerting a team when inventory drops below a threshold, for example — with no client left running. 

Rounding it out: a Skill Catalog for discovering and reusing proven agent skills across the enterprise. The pattern is clear — the agent should show up where the work already happens, not ask the work to move to it. 

3. Context is the new moat 

This was the takeaway I underlined twice. The biggest constraint on enterprise AI is no longer model quality it is whether the model understands your business. Snowflake leaned hard into this with a cluster of context-and-semantics announcements. 

Horizon Context (private preview) adds the ability to collect metadata from outside systems — PostgreSQL, SQL Server, Tableau, Power BI, dbt — then enrich it with column-level lineage and AI-generated documentation, and activate it through hybrid semantic search. Semantic Studio and Semantic View Autopilot let teams define and auto-maintain shared business logic without deep SQL expertise. 

The number that landed hardest came from Cortex Sense, the runtime layer that assembles data, business definitions, and operational knowledge for an agent at query time: 86% accuracy on structured business questions with full context, versus 24% for a generic model without it. Same question, same model class — the difference is context. That gap is the entire argument for why a governed semantic layer matters, and it is the slide I will be screenshotting for client conversations. 

4. Agents need identity — and now they have one 

Here is the part most of the press underplayed and most security leaders should not. Snowflake shipped AI Agent Identity (GA): every agent now gets a cryptographic identity, per-agent role-based access control (RBAC), and a complete audit trail. Pair it with the new AI Security Posture Management and you have the beginnings of a governance model built for non-human actors. 

Think about what an autonomous agent actually is — software that reads data and takes action on its own. Without identity, RBAC, and auditability, that’s an ungoverned service account with initiative. Treating agents as first-class identities is the unglamorous prerequisite that makes everything else safe to deploy. I expect this to become table stakes, and the organizations that get their identity and access model right early will move faster later. 

5. The plumbing kept advancing, too 

Underneath the agent headlines, the infrastructure announcements were substantial — and they are what make the agent story credible: 

• Snowflake Datastream — a fully managed, Kafka-compatible streaming service. Existing Kafka producers and consumers connect with a config change, and data lands as governed Snowflake or Iceberg tables. Snowflake pegs the real-time data opportunity at $128B. 

• Apache Iceberg v3 (GA) — bidirectional interoperability via the Horizon Catalog, which embeds the open-source Apache Polaris catalog. The open-table-format bet is now fully in production. 

• Cortex Training + Adaptive Compute — fine-tune open models like Qwen and Mistral on managed GPUs without moving data outside the governed perimeter. 

• Ecosystem moves — an expanded Anthropic partnership, a reported $6B AWS commitment, the Natoma acquisition, and the dbt + Fivetran merger reshaping the data tooling map. 

6. The Anthropic moment 

The expanded Anthropic partnership, and the ability to drive Snowflake work directly from Claude, signals where Snowflake believes the value is migrating: toward reasoning over governed enterprise data, not just storing and serving it. 

What I took from that fireside is a posture, not just a product. The two companies framed enterprise AI as a division of labor — the model brings reasoning, the platform brings governed context and guardrails. Neither is sufficient alone. For anyone deciding how to build, that framing is a useful corrective to the assumption that a powerful model, dropped onto messy data, will somehow figure it out. It won’t. The demo that worked was always the one with clean semantics behind it. 

What I’ll be watching next 

A recap is easy; the hard questions take longer to answer. A few I left San Francisco still chewing on. First, how much of this is GA versus preview? Several of the most exciting capabilities — Horizon Context, Datastream, Semantic Studio — shipped in private or public preview, which means the real test is the next two quarters of customer hands-on time. 

Second, does the context layer reach far enough? Cortex Sense is powerful inside Snowflake’s boundary, but most enterprises run across many systems. How well the metadata connectors and lineage stretch across a genuinely heterogeneous estate will decide whether the 86% number holds up outside a demo. 

Third, what does this do to cost? Agents that run on schedules and react to events are, by design, always working. The FinOps conversation around autonomous, event-driven compute is one almost nobody had on stage — and one every platform team will have within a year. 

The Real Takeaway 

Snowflake spent Summit 2026 making one bet out loud: that the winners in enterprise AI will be the organizations whose data is governed, whose context is engineered, and whose agents are identified and accountable. The compute was always going to get cheaper. The trustworthy foundation is the hard part — and the part worth investing in now. 

For more information on our Snowflake capabilities, visit our Snowflake Partner page.

The post Six Takeaways from Snowflake Summit 2026 appeared first on Perficient Blogs.

I felt that often last week at Salesforce Connections in Chicago — and it sharpened a question I keep coming back to: what does agentic enterprise transformation actually require of a marketing organization, before the demos, and long after the conference ends? I also had the opportunity to share my real-time reactions with a room full of marketers at Perficient’s keynote breakfast watch party. What I shared there is what I want to capture here: the announcements were impressive, but the more important conversation is what they signal — and what it will take for organizations to turn that potential into impact.

The Demos Were Good. The Subtext Was Better.

The Salesforce Connections keynote was organized around three chapters: Always-on Creativity, Self-Optimizing Campaigns, and Autonomous Pipeline Generation. The demos across all three were compelling. Agentforce Co-Worker surfaced marketing-driven pipeline insights in minutes instead of weeks. The Goals Agent compressed a campaign lifecycle from 12 to 14 weeks down to hours. Piper, the Qualified SDR Agent, accelerates lead qualification and meeting creation 24/7. And the acquisition of Contentful pointed to more dynamic control over creative assets that have historically been locked inside rigid content systems.

What stood out to me, though, was not any one announcement in isolation. It was that each of them addressed the same underlying problem: marketing operates on lag. Insights arrive after the window to act has passed. Content approvals outlast campaign relevance. Buyers move faster than the systems designed to engage them. Across all three chapters, Salesforce was presenting a coordinated attempt to shrink that latency and move marketing closer to real time.

That’s what makes the strategic case compelling. The problem is rarely that marketers lack data or ideas. It’s that turning those inputs into action still takes too many handoffs and too much time. If these tools meaningfully reduce that delay, the advantage is not just speed. It’s operating on a different wavelength than competitors still constrained by manual workflows.

That, to me, was the keynote’s real headline.

Here’s the Part I Said Out Loud in That Breakfast Room

What I also said is that none of this works by magic. My job is not just to admire what the technology can do. It’s to help clients understand what conditions must be true for it to work well. When it comes to AI agents, that means being honest about something marketers need to hear more often: agents do not remove the need for operational maturity. They make it more visible.

An agent tasked with building campaigns will only be as effective as the goals and constraints you give it. An agent generating content will only be as on-brand as the standards and approvals model you make accessible to it. A pipeline agent can scale good qualification discipline, but it can also scale confusion if marketing and sales have never aligned on what qualified means. And an intelligence dashboard can produce fast, confident-looking outputs that are only as trustworthy as the data beneath them.

That is not a criticism of Salesforce. It is the operating reality of agentic AI, and it is probably the most useful thing I can say after watching the keynote. The maturity requirement is not primarily technical. It is organizational. Can you define a good campaign brief in writing? Do you have benchmark data that can guide decisions? Have marketing and sales aligned on lead quality? Is your CRM data complete enough to trust?

Those are the questions that separate organizations that will realize meaningful value from those that will run a pilot, get mediocre output, and decide the technology is not ready. In many cases, the technology is ready. The foundation is what needs attention.

Starting Your Agentic Enterprise Transformation: Where to Focus First

If your team is still early in its AI maturity, the most valuable thing you can do right now is not deploy an agent for the sake of having one. It is to strengthen the operating conditions an agent will depend on. That means auditing data completeness in Salesforce, establishing attribution frameworks people use consistently, and documenting your brand’s voice and campaign standards in a format structured enough for a machine to follow. In practical terms, you are writing the brief an agent will eventually execute against.

If you already have a strong data foundation, the opportunity is not to treat these agents as a linear progression from one capability to the next. Marketing doesn’t work that way. The real opportunity is to connect the intelligence, campaign, and pipeline layers, so they continuously inform one another. That closed loop is the real prize: not a single agent or workflow, but a system in which each capability makes the others more effective.

What We’ve Learned at Perficient: Our Agentic Enterprise Transformation

We’re a Salesforce Agentforce implementation partner, and we’ve been building this architecture in our own go-to-market operations, so I’m not speaking hypothetically. Our internal data was sobering. Fifty-nine percent of our sellers were spending 40 percent or more of their week on non-selling activities, and they rated their tools at 3.9 out of 10. Marketing’s work was disappearing into that capacity gap, with leads untouched, intent ignored, and content missing the moment it was meant to influence.

Our answer was an Agentic Front Office: seven specialized agents deployed directly into the Salesforce and Slack workflows where our teams already work, guided by three principles. First, unlock the context agents need to be useful. Second, right-size their responsibilities with bounded roles and clear guardrails. Third, prepare the workforce to orchestrate outcomes alongside digital labor, rather than execute manual tasks.

What building this has reinforced for me is that this is an operating model change, not a feature upgrade. The organizations that get the most from this moment will pair ambition with discipline. They will invest in the data, alignment, governance, and change management required to make agents effective, while also moving quickly enough to learn by doing. Those are the organizations that will look back at Connections 2026 and recognize it as the moment their agentic enterprise transformation stopped feeling theoretical — and started becoming operational.

The post Agentic Enterprise Transformation: What Marketers Need to Hear After Connections appeared first on Perficient Blogs.

This blog was written by both Megan Mueller Jensen and Randy Roosekrans, supporters and members of PRISM, Perficient’s Employee Resource Group for our LGBTQIA2S+ colleagues and allies.

As cisgender straight people in a professional setting, we believe it’s our responsibility to do our best to support our LGBTQIA2S+ colleagues. We are longtime allies, advocates, activists, and parents of gay kiddos, and we want to share a few things we’ve learned over the years about making our workplaces safer, friendlier, more inclusive, and more supportive for our queer colleagues. (For the rest of this writing, we’ll refer to these folx as ‘queer,’ which is an umbrella term although we recognize that not all of this applies to everyone.)

1. Pronouns matter. If someone tells you their pronouns, the bare minimum we can do is respect that and use those pronouns consistently. And if you slip up in conversation, correct yourself, apologize briefly, and move on. Doing so will signal that you’re making an effort; it becomes easier with practice. If you’re not sure of someone’s pronouns, it’s ok to ask! Simply say, “I use she/her. May I ask what you use?” It’s also great to include your pronouns in your email signature, when introducing yourself, joining a meeting, or on your LinkedIn profile. It’s a positive signal that lets queer folx know that you’re a safe colleague and partner to work with, and that they’re cool being themselves around you.
2. Respect and protect the privacy of your queer colleagues. Just because someone has disclosed information to you (or within PRISM events and conversations) doesn’t mean you have permission to share that with anyone outside of that original conversation. It’s ONLY the decision of queer people themselves to whom they want to come out. That information may not be safe or smart to share anywhere else. If for some reason it’s necessary to divulge details about others, make sure you get their permission first.
3. Educate Yourself. Take the initiative to educate yourself about queer issues, terminology, and experiences. There are plenty of resources available online, such as articles, books, and documentaries that can help you understand the challenges faced by the queer community. While most queer folx are happy to answer questions, it can also be emotionally and intellectually exhausting to constantly be the sole source of information, or if there is an assumption that they “represent” all queer folx.  A few great resources include HRC (Human Rights Campaign),  GLAAD (Gay and Lesbian Alliance Against Defamation), and The Trevor Project. PRISM also hosts informational events throughout the year that are designed to help us all be better allies.
4. Speak up, even (or especially) when queer colleagues aren’t present. If someone misgenders a colleague or uses offensive terminology, intentionally or unintentionally, it’s our responsibility to correct them in a friendly but consistent way. Stand up for folx who aren’t in the room. It sets the standard for expected behavior within the team and reinforces a supportive company culture. To that end, be very mindful of “deadnaming” which is using the name a trans person had before they changed it to what they use now. It can be deeply traumatic and triggering for them to hear that name in any setting. If you happen to make that mistake, you can offer a quick, sincere apology and keep the conversation moving.  If you hear a colleague using the deadname of someone who isn’t present, it’s a good opportunity for a friendly correction.
5. Support queer-inclusive policies. The needs and challenges of our queer colleagues may be different and more impactful than ones we experience as cisgender folx. Don’t make them fight for equality and inclusivity alone. Make sure they know you are in their corner and follow that sentiment with action.
6. Remember it’s not about YOU. As allies, it’s our job to support, facilitate, and enable the efforts of our queer colleagues. Big decisions should be made by queer folx, and our role is to help make their lives easier, safer, and more equitable. Try your best to give input, ideas, and opinions regarding queer life when invited to do so or ask if you can add your perspective when it might be useful.
7. Be open to listening and open to growth. Even with the best of intentions, we won’t always get it right. We may unintentionally say something dumb or stumble over our words. If a queer colleague corrects you or gives you input, see it as a sign of trust rather than criticism.

Understand that there are many facets to queer culture, and some norms may vary. The more exposure and practice you get in these spaces, the clearer those norms will become. The most important thing is that you approach these interactions with respect — everything else falls into place!

In closing, CONGRATULATIONS TO YOU! The fact that you are reading this article and showing an interest in this topic demonstrates your allyship, and your willingness to help make positive changes within the queer community. Thank you for being who you are! Let’s help our colleagues, clients, friends, and loved ones in the queer community feel welcome to be the best versions of themselves, too!

The post 7 Ways to Be a Better LGBTQ+ Ally at Work appeared first on Perficient Blogs.

Earning the AWS Golden Jacket is a remarkable accomplishment—one that reflects deep technical expertise, persistence, and a commitment to continuous learning across the AWS ecosystem.

What Is the AWS Golden Jacket?

The AWS Golden Jacket is a recognition given to individuals who hold all active AWS certifications at the same time, demonstrating expertise across the full breadth of AWS capabilities, including cloud architecture, DevOps, security, data, and machine learning.

Because it requires maintaining every certification concurrently, this distinction signals both depth and breadth of knowledge across AWS services and domains.

What This Achievement Represents

Earning the AWS Golden Jacket reflects more than completing a set of certifications. It represents sustained focus, discipline, and the ability to operate across a rapidly evolving cloud ecosystem.

To reach this level, Gonzalo built and maintained expertise across a wide range of AWS services and domains, while continuously adapting as the platform evolves.

This includes:

• Mastering AWS services across architecture, security, data, and AI/ML
• Maintaining all certifications simultaneously as they evolve and require renewal
• Applying knowledge to real-world scenarios where design decisions impact scalability, performance, and cost
• Staying current with new services, architectural patterns, and best practices
• Balancing ongoing learning with day-to-day client delivery

That level of commitment signals expertise that stays current as AWS continues to innovate.

For our clients, that translates into real value. It means working with experts who can connect capabilities across AWS services and design solutions with a clear understanding of how to align technology decisions to business outcomes.

Powering Our AWS Practice

Gonzalo’s achievement reflects the strength of Perficient’s AWS practice and the expertise we bring to clients as an AWS Premier Consulting Partner.

Our teams deliver solutions aligned to key AWS capability areas, including:

• Cloud architecture and modernization
• Data and analytics platforms
• Security and compliance
• Artificial intelligence and machine learning

This work is backed by:

• Deep, cross-functional cloud expertise
• A strong culture of certification and continuous learning
• Proven experience delivering complex, enterprise-scale AWS solutions
• A focus on driving measurable business outcomes

A Milestone Worth Celebrating

The AWS Golden Jacket is a significant achievement that reflects both individual dedication and the collective strength of our AWS practice.

Gonzalo, congratulations on this well-earned recognition. Your expertise, curiosity, and commitment to continuous learning make a meaningful impact on our clients and our team. We’re proud to celebrate this moment and look forward to what comes next!

Read more about Perficient’s AWS practice here.

The post Celebrating Gonzalo Munoz’s AWS Golden Jacket: A Milestone That Reflects Excellence appeared first on Perficient Blogs.

Headless Page-based Authoring Tutorial Preface

This tutorial assumes that you have a basic understanding of Universal Editor’s purpose and AEM’s architecture. It is also not intended to be a comprehensive solution design for the AEM-App integration nor a complete Universal Editor tutorial. Considerations like instrumentation details, caching, app security, and which authoring options are made available are beyond the scope of this tutorial.

Step 1: Enable AEM Page Content for Export

You can certainly use the pre-configured model JSONs of AEM Core Components. However, they have several fields that are not relevant to my downstream application, like gridClassNames and allowedComponents.

So instead, I prefer custom Sling Models. This gives us a granular level of control over which fields are exposed to our downstream application.

Start by creating a Sling Model for your Page component. Configure the @Model annotation to utilize SlingHttpServletRequest.class as an adaptable so it can serve web requests to a .model.json path and match the resourceType property to the resourceType of your Page component. Configure the @Exporter annotation to use the Jackson library and support a JSON extension for export.

You’ll notice that I’ve created a getItems method that returns a list of objects. This method utilizes a custom HeadlessUtils method that looks for (almost) all children resources of the Page and adapts them to their matching model based on their sling:resourceType. This is very important, as we want each child component to export its JSON based on its own model, not relying solely on the model of the parent.

I can re-use this pattern for other container components, components like Responsive Grids or Columns that have any number, names, and types of children.

Then I can similarly configure Sling Models for all components that will appear on my page. The primary difference in how I configure these other component models is that they also need to be adaptable from a Resource in order to be exported by the getItems method or other resource-based retrieval.

Once I have done that, I can load the export of any Page that uses this model as JSON.

Step 2: Consume the Page Content Downstream

For this example, let’s create a small connector library to AEM using JavaScript. Ultimately this could be run server-side or client-side and rendered however I like. The purpose here is to show that regardless of what downstream app I have, I can use a simple REST-based GET to retrieve the data.

You may notice within the code here that I’ve abstracted out the concept of a full AEM path from the rest of my application. This is because I don’t want to force the downstream application to adhere to a specific route structure. Perhaps in my app, locale is determined by the domain and not the application route.

Further, though I want to display published content on production, I still want to edit content in the AEM author environment before I review and publish it out. If I don’t have an “author” version of my downstream app, I need a different means to instruct the app to pull from the author environment. So I use 4 key parameters:

1. The matching AEM base path – This comes statically from my route. I do not allow open-ended user-editable paths for security reasons.
2. (MSM support) Do I want to view the language-master or the rolled out live-copy?
3. (MSM support) What locale am I in?
4. Am I currently authoring?

The latter 3 act as flags which modify the base path. These flags could come from URL parameters, session storage, cookies, etc. In my case, I use URL parameters because I do not want cached AEM content while authoring.

Now, in a real implementation, to access page content in an author environment, my code needs to authenticate to AEM. This can be done via a technical account (preferred) or temporary developer token. Select one of the options linked, follow the instructions, and then come back.

Publish environment content is typically public and therefore does not require an authentication token.

Step 3: Configure AEM to Open Pages in Universal Editor

Now that I have my Page Model rendering in my downstream application, I can configure AEM to open pages of a particular path and sling:resourceType in Universal Editor. This is done by adding an OSGI configuration for the Universal Editor URL Service, which you can also read more about in Adobe’s documentation.

The mappings field has two parts: the parent path for which the Universal Editor should be opened and the target downstream application domain. [parentPath:applicationDomain]

The resourcetypes field defines the sling:resourceTypes that should be opened in Universal Editor. In our case, this is our page component.

The aemDomain field signifies that the Universal Editor should be opened on the same domain as AEM. This is critical, as being on the same domain allows sharing our user’s Adobe IMS login token with Universal Editor. This login token is later used by the Universal Editor to write back our authoring changes to the JCR.

Now authors can click the Edit button in AEM Sites Admin and have the “page” open in the context of the downstream application with Universal Editor.

This one step helps close the loop for authors. We’ve moved Universal Editor authoring as a separate domain authoring tool to integration directly with AEM. It also allows authors to continue to think about downstream app routes as “pages” in AEM even though they aren’t being rendered by AEM.

As an aside, you might notice that I’ve specified a /preview route in the downstream application; why did I do that? AEM doesn’t know which downstream app route to open for a given page. All it can do in this integration is pass details like the AEM content path.

As I said earlier, I don’t want to force my downstream application to adhere to a specific route structure. I certainly could do that; I could update the mappings field to “/content/nextDayAEM:localhost:3000/${path}”.

This would make the page /content/nextDayAEM/language-masters/en_us open like localhost:3000/content/nextDayAEM/language-masters/en_us instead. But now my app has to handle any number of route combinations.

So instead I use a common /preview path and let the downstream application figure out what route maps to the aemPath parameter and do an internal redirect, passing those 4 key parameters I identified earlier. If I’ve configured everything correctly, the downstream route + parameters should match exactly 1 AEM page.

Step 4: Write Authored Content Back to AEM

Now move on to instrument the downstream application for Universal Editor. This step involves loading the Universal Editor script, adding data-aue-* attributes to your downstream app components, and adding JSON configuration files. All of that really requires its own tutorial. So I’m going to send you over to Adobe to explain that part, but note that this example uses content fragments. The only major difference in this instrumentation for page-based resources is in the Component Definition JSON, where you should specify the plugin property as “aem” :{ “page”: {..} } instead of “aem” :{ “cf”: {..} }.

Now that all of that is complete, I should be able to log in to AEM and edit a “page.” As far as the authors are concerned, all that’s changed is a new page editor experience. This has far more ramifications than you might expect at first glance. Let’s review the headless challenges we identified from last week.

1. How does an author track content downstream from the CMS? Content is now tracked 1:1 with a “page” that matches a downstream route.
2. Useful AEM Page tooling is not available out of the box for Content Fragments. We’re now able to use Page-based tooling like link browsing, asset page references, link rewrites on moves, page launches, MSM, etc.
3. Link checker no longer functions, as AEM does not have any inherent knowledge of the downstream routes. Though AEM can’t directly check the downstream routes, it can check AEM page-to-AEM-page links.  You can have authors link them as AEM paths via the page browser and use the same route mapper you developed in Step 3 to render the links.
4. Downstream applications pull in fragments by name or by query. Whereas Content Fragments had to have unique names, Pages, due to page hierarchy, can always match the route name.
5. Existing AEM authors are typically more experienced with creating and managing pages instead of content fragments. Fixed.
6. It creates a platform disconnect. Authors must navigate to AEM to create Content Fragments but navigate to the downstream application or the Universal Editor to view changes in context. Universal Editor now exists on the same domain as AEM. It looks like part of AEM, not a separate tool.

In other words, many of the challenges we faced with a headless AEM experience are no longer relevant when we use page-based resources as the source. We’re able to leverage the strengths of traditional AEM Page Tooling because, as far as AEM and JCR are concerned, this content exists as real pages in AEM, even though all rendering can take place outside of AEM.

I hope this makes you as excited as I am, as Headless experiences just got a whole lot easier to manage!

What’s Next?

Have a tutorial you’d like to see next?  For more information on how Perficient can implement your dream digital experiences, we’d love to hear from you. We’re certified by Adobe for our proven capabilities, and we hold an Adobe Experience Manager specialization (among others).

Contact Perficient to start your journey.

The post Implementing Headless Page-based Authoring in Adobe’s Universal Editor: Part 2 appeared first on Perficient Blogs.