When Context Doesn't Govern AI, AI Governs the Solution

Moises Griott — Thu, 11 Jun 2026 20:35:18 +0000

Over the last few months, I've spent a significant amount of time working with AI coding assistants, agentic IDEs, MCP-based architectures, and AI-assisted development workflows.

Like many engineers and architects, I was amazed by the speed.

Features that previously took days could be built in hours. Boilerplate disappeared. Documentation became easier. Prototypes emerged almost instantly.

At first, everything looked great.

We started with a clear architecture, defined principles, and a solid technical vision. The AI accelerated implementation and helped us move faster than ever before.

Then something interesting happened.

After dozens—or sometimes hundreds—of interactions, we began noticing subtle changes across the solution.

Individual changes looked reasonable.

The problem appeared only when we stepped back and looked at the system as a whole.

We found ourselves asking questions such as:

When did the architecture change?
Who decided this new approach?
Why is this module following a different pattern?
When did we stop following the original design?
How did the code become something I no longer fully control?

The reality was surprisingly simple.

The AI wasn't following a governed architecture.

It was responding to the partial context available at each interaction.

Every individual suggestion made sense.

Every individual optimization looked correct.

But over time, those local optimizations started creating architectural drift.

A component changed.

A pattern evolved.

A new abstraction appeared.

A different architectural style emerged.

No single decision seemed problematic.

Yet the overall solution gradually moved away from its original design.

The issue wasn't code generation.

The issue wasn't AI quality.

The issue was the absence of a strategy to govern the context that guides the AI.

Most discussions around AI-assisted development focus on prompts, models, agents, or coding tools.

Very few focus on what I now believe is the most important asset in an AI-driven project:

Context.

Architecture decisions.

Business rules.

Constraints.

Domain knowledge.

Design principles.

Technical standards.

All of these elements form the context that should guide the AI.

Without a governed context, the AI naturally optimizes based on whatever information is available in the current interaction.

And that is where the problem begins.

As I reflected on this challenge, I started thinking about a different approach.

What if we treated context as a first-class engineering asset?

What if architecture, principles, constraints, and domain knowledge became the primary source of truth?

What if AI systems were required to operate within a governed context instead of continuously redefining it?

These ideas eventually evolved into a framework I am currently exploring:

CDAD — Context-Driven AI Development

The core idea is simple:

The AI may suggest.
The AI may analyze.
The AI may accelerate.
But the AI should not redefine the architecture without explicit approval.

CDAD is built around several principles:

Context Engineering
Governance of Context
Context Protection Pattern (CPP)
Markdown-Driven Development
Agentic Development Environments (ADE)
AI-Assisted Delivery

The goal is not to limit AI.

The goal is to ensure that AI accelerates implementation without taking ownership of architectural decisions.

In this model:

Architecture lives in the context.
The context becomes the source of truth.
The AI operates on that context.
Humans remain responsible for the evolution of the solution.

This is still an evolving idea, but it has already changed how I approach AI-assisted development.

The biggest lesson so far is surprisingly simple:

When context doesn't govern AI, AI governs the solution.

And perhaps an even stronger statement:

Context is the new Source Code.

I'm curious to hear from other architects, engineers, and AI practitioners.

Have you experienced architectural drift while working with AI coding assistants or agentic development environments?

If so, how are you governing the context that guides your AI systems?

Building Agentic Architectures with AutoGen and Groq: Notes from My PoCs

Moises Griott — Tue, 09 Jun 2026 21:05:37 +0000

By Moisés Griott – Digital Architect | Cloud & Agentic AI

As a Digital Architect, most of my career has been focused on cloud platforms, distributed systems, microservices, and enterprise integration.

the last year, I have been exploring Agentic AI, Multi-Agent Systems, and MCP-related architectures. Instead of only reading about them, I decided to build several PoCs using AutoGen and Groq to understand their strengths and limitations in practice.

One of the questions that motivated these experiments was:

``Kubernetes solved container orchestration. Who will orchestrate AI agents?

Why AutoGen and Groq?

For my experiments, I wanted a solution that was simple to set up and allowed me to focus on architecture rather than infrastructure.

AutoGen provided an easy way to create specialized agents and coordinate conversations between them.

Groq offered low latency and a straightforward developer experience, making it ideal for rapid prototyping.

What I Built

My PoCs focused on a simple pattern:

Instead of having one agent responsible for everything, each agent had a specific responsibility:

Reasoning and analysis
Knowledge retrieval (RAG)
External actions such as notifications

This approach felt very familiar to someone coming from a microservices background.

Looking Ahead

The more I experiment with Agentic AI, the more I see similarities with the early days of microservices and cloud-native architectures.

The tools are evolving rapidly, but many architectural principles remain the same:

Separation of concerns
Scalability
Observability
Loose coupling
Clear responsibilities

I believe we are only beginning to discover the patterns that will define enterprise Agentic AI architectures in the coming years.

For now, the best way to learn is simple:

Build PoCs, experiment, and understand where these architectures create real value.

About the Author

Moisés Griott
Digital Architect | Cloud | Distributed Systems | Agentic AI

Currently exploring Multi-Agent Systems, MCP architectures, AutoGen, Groq, and the future of enterprise AI platforms.

DEV Community: Moises Griott

When Context Doesn't Govern AI, AI Governs the Solution

Building Agentic Architectures with AutoGen and Groq: Notes from My PoCs