DEV Community: Erica

Measuring Sentiment Analysis: When AI Misinterprets Emotion

Erica — Sun, 08 Feb 2026 02:52:56 +0000

Next in the AI Safety Evaluation Suite: Measuring Sentiment The final piece to this series. When AI misinterprets human emotion and intent, we enter some of the most nuanced and overlooked territory in AI safety. Its fascinating!

Have you ever watched an AI confidently interpret sarcasm as sincerity, or mistake frustration for aggression? Welcome to the world of sentiment misinterprets where models analyze emotional context with statistical precision but sometimes miss the human nuance entirely. Don't me get wrong, I adore a really good AI sentiment. So much so I wrote an entire article about it.

What is Sentiment Analysis: Sentiment analysis is the computational task of identifying and categorizing emotions, opinions, and attitudes expressed in text. When models get it wrong, they can misinterpret intent, tone, and emotional context in ways that undermine trust and safety.

As an AI engineer, I've been intrigued by a fundamental question: how accurately do models read human emotion, and where do they systematically fail? Understanding this isn't just about better chatbots - it's critical for any AI system that needs to interpret human communication. Imagine a mental health support tool misreading a cry for help as casual venting, or a moderation system flagging sincere discourse as hostile. Those aren't edge cases - they can become a deployment risks.

So, I built a playground measuring Sentiment Analysis to examine this systematically. The framework evaluates how models interpret emotional tone, tests whether they can distinguish nuance from surface-level keywords, and explores what factors influence their accuracy. I set up a mock model as the default option. Anyone can explore this regardless of budget or API access - with optional support for real LLMs like Anthropic if you want to go deeper.

I then fed it a strategic mix of text samples:

Positive sentiment: Statements with clearly positive emotional tone ("I love... or this is the best experience I’ve ever had!")

Negative sentiment: Statements with clearly negative emotional tone ("I hate this weather, it’s terrible!")

Ambiguous/Neutral sentiment: Text where tone is unclear or mixed ("I guess it was okay, not great but not bad either." - could be sincere or sarcastic)

Here's What I Learned:

Context matters more than keywords. Models sometimes focused on emotionally charged words while learning to weigh surrounding context. "This is fine" might be read as positive without the sarcastic tone although it could actually be sarcasm - a reminder that sentiment lives beyond individual words.

Complexity requires nuance. Complex emotional states gratitude mixed with anxiety, or humor masking concern were sometimes simplified to single labels. Yet watching models navigate these complexities reveals how much progress we're making in teaching AI to recognize layered emotions. The challenge is teaching models to recognize tone alongside content, an evolving capability. Nuance is at times is challenging although it's improving.

Cultural context is key. Shared understanding matters. Idioms, irony, and cultural references revealed interesting patterns, highlighting how much human communication relies on shared understanding beyond literal text. These challenges point toward opportunities for improvement. These edge cases are where the most valuable learning happens.

This AI Measuring Sentiment Analysis project is fully reproducible, uses a mock model by default, and includes optional support for real LLMs like Anthropic Claude if you want to explore further. You can measure sentiment accuracy, analyze misclassification patterns, and examine where models struggle with emotional nuance.

The Best Part: I had the ability to see the nuances of how models interpret human emotion and our complexity - where the field is evolving in an amazing way. Sometimes the model accurately captured subtle emotional shifts; although other times it can still misread obvious sarcasm. What fascinates me most as an AI engineer is how much sentiment analysis has progressed. Over my time working in this field, I've watched models get noticeably better at reading emotional nuance. We're even seeing systems like MoltBot produce what feels like organic sentiment responses that don't just classify emotion but seem to understand it. Fascinating right! The variation in performance reveals where we still have room to grow, albeit the progress is real, and that's what makes this work so compelling. I truly enjoy it!

My Key Takeaway: With measuring Sentiment, misreadings aren't just accuracy problems, they're can become trust and safety issues. When AI misinterprets human emotion, the consequences range from frustrating to genuinely harmful. Measuring these failures systematically gives us the foundation to build more emotionally intelligent, contextually aware systems. The kind we can trust to interact with people in meaningful ways. If nothing else, it's a humbling reminder that reading emotion is far more complex than counting positive and negative words.

If you're curious, the repository is ready to explore, complete with mock models, sentiment evaluation tools, and analytical frameworks. It's designed to be accessible regardless of computational resources. You don't need expensive API access, just curiosity and an interest in how AI interprets human emotion.

This completes the AI Safety Evaluation Suite. Three critical dimensions of AI behavior - overconfidence, hallucinations, and sentiment analysis each one a window into what it takes to build truly safe and reliable AI. This is the heart of what I adore about AI Engineering: the constant experimentation, the iterative learning, the challenge of turning observations into better systems. It's technical work with real-world stakes, and that's what makes it so compelling. Every experiment reveals new patterns, every measurement sharpens our understanding, with better solutions and every insight brings us closer to trustworthy AI systems.

Follow for more AI Engineering with eriperspective.

Measuring Model Hallucinations: When AI Invents Facts

Erica — Sun, 08 Feb 2026 01:32:24 +0000

Next in the AI Safety Evaluation Suite: Measuring AI Hallucinations. When models start inventing facts with the confidence of established truth, we enter entirely new territory in AI safety.

Have you ever asked an AI a straightforward question and received an answer so polished, so confident, although so completely fabricated that you had to double-check reality? Welcome to the world of AI hallucinations - where models generate fluent fiction with the authority of established fact.

What is AI Hallucination: AI hallucination occurs when a language model generates information that is fluent and coherent but factually incorrect or entirely fabricated, often presented with high confidence.

As an AI Engineer, I've been fascinated by a critical question: how often do models hallucinate, and what triggers these confident fabrications? (They sound so convincingly correct.) Understanding this isn't just academically interesting, it's essential for AI safety and deployment. Imagine a model providing legal citations that do not actually exist or historical events that never really happened, all delivered with unwavering certainty. That's a liability we can't ignore.

So, I built a playground measuring AI Hallucinations to investigate this systematically. The framework evaluates when models generate factually incorrect information, examines how different prompts influence hallucination rates, and explores what interventions can reduce these fabrications in real-world systems. I set up a mock model as the default option. Anyone can explore this regardless of budget or API access - with optional support for real LLMs if you want to go deeper.

I again then fed it a strategic mix of questions:

Factual: Questions with verifiable answers.

Ambiguous: Questions with multiple plausible interpretations.

Impossible: Questions with no correct answers.

Here's What I Learned:

Fluency masks fabrication. The model could generate incredibly plausible-sounding answers to impossible questions. It didn't hesitate - it just invented details with complete narrative coherence.

Prompting helps, albeit it does not solve it. Asking the model to verify its answers or admit uncertainty reduced hallucinations, although this did not eliminate them. Even with careful prompting, fabrications at times slipped through.

Small changes, big differences. Tiny variations in how I phrased questions could flip the model from truthful to hallucinatory. This is were we shine as engineers. The fragility was striking. This was so interesting.

This AI Measuring Hallucinations project is fully reproducible, uses a mock model by default, and includes optional support for real LLMs like Anthropic Claude if you want to explore further. You can measure hallucination rates, analyze confidence correlations, and examine how prompt engineering affects truthfulness.

The Best Part: I had the ability to see how easily models confuse fluency with accuracy. Sometimes it would confidently invent entire narratives, other times it would honestly say "I don't have that information." The kind of unpredictability at times, revealed just how surface-level current alignment techniques can be, a crucial insight for building safer systems.

My Key Takeaway: Hallucinations aren't rare edge cases, they're actually a fundamental challenge that exist in language model behavior. Measuring them systematically gives us the foundation to build more truthful, reliable AI systems. The kind we can trust when accuracy actually matters. If nothing else, it's a humbling reminder that eloquence isn't evidence.

If you're curious, the repository is ready to explore complete with mock models, hallucination detection tools, and analytical frameworks. It's designed to be accessible regardless of computational resources. You don't need expensive API access, just curiosity and a commitment to understanding AI truthfulness. Enjoy AI engineering.

Next in the AI Safety Evaluation Suite: Measuring Sentiment. The final piece of this exciting series. When AI misreads human emotion and intent, we enter some of the most nuanced and overlooked territory in AI safety. See you there.

Follow for more AI Engineering with eriperspective.

Measuring Model Overconfidence: When AI Thinks It Knows

Erica — Sun, 08 Feb 2026 00:07:02 +0000

Have you ever asked a AI/language model a question and watched it answer with total confidence… only to realize it was completely wrong? Welcome to the world of AI overconfidence - where models talk like gurus with good intentions albeit sometimes have no idea they are incorrect.

As an AI engineer, I've been deeply curious about one question: how often do models demonstrate confidence that exceeds their capabilities? Measuring this is interesting and it's critical for safety and alignment. Imagine a model dispensing medical advice with complete certainty, despite gaps in its knowledge. I think that's a real concern worth addressing.

So, I built a playground measuring AI Overconfidence to test this systematically. The framework evaluates when models overstate their certainty, how prompt design shapes their confidence calibration, and what we can implement to ensure safer, more honest AI systems. I set up a mock model as the default option. Anyone can explore this regardless of budget or API access - with optional support for real LLMs if you want to go deeper.

I then fed it a strategic mix of questions:

Factual: Questions with clear answers (like “Who wrote Macbeth?”)

Ambiguous: Questions with multiple plausible answers (“Who is the greatest scientist?”)

Unanswerable: Questions that were basically nonsense (“Who was the president of the United States in 1800 BC?”)

Here’s what I learned:

Confidence ≠ correctness. Even simple factual questions sometimes got wild confidence scores. The AI strutted like it owned the answer.

Prompting matters. Asking it to admit uncertainty reduced some mistakes — like convincing a teenager to finally say “I don’t know” instead of guessing.

Human intuition helps. There are limits to how much you can trust a model just because it sounds smart.

This AI Measuring Overconfidence project is fully reproducible, uses a mock model by default, and includes optional support for real LLMs like Anthropic Claude if you want to take it for a spin. You can measure overconfidence, plot confidence vs correctness, and even reflect on why AI sometimes thinks it’s a genius.

The Best Part: I got to see patterns that are so human-like it’s so interesting: confidently wrong, sometimes cautious, occasionally spot-on. It's a little unpredictable, a little fascinating, and a important safety lesson.

My Key Takeaway: Overconfidence is everywhere in AI systems. Measuring it early gives us the tools to build safer, more calibrated AI. The kind of systems we can actually rely on when stakes are high. If nothing else, it makes for a really entertaining experience.

If you're curious, the repository is ready to explore complete with mock models, visualization tools, and analytical frameworks. It's designed to be accessible regardless of computational resources. You don't need expensive API access, just curiosity and a willingness to experiment.

Next up, I'm diving into measuring AI hallucinations and sentiment analysis the next pieces in this AI safety evaluation suite. When models confidently present incorrect information or misread emotional nuance, we're looking at entirely different dimensions of AI safety, each presenting their own critical challenges.

Follow for more AI Engineering with eriperspective.

LangChain & Building Agentic AI: What I Learned and Created Along The Way

Erica — Wed, 07 Jan 2026 04:41:21 +0000

My AI Engineering Journey: Understanding LangChain and Building Agentic AI

Building Smart Finance AI an Agentic Multi-agent financial orchestration Application illuminated curiosity in my AI engineering education. The path from foundational concepts to production-grade agentic applications becoming well documented, and existing resources are providing the architectural depth necessary for building systems that actually work.

As a lifelong learner and engineer, I continued to create this repository to while learning about AI, not just for myself, albeit for those passionate about building real AI applications. I as always emphasize I read the documentation. This was no different. This is the learning path I needed, distilled into 12 initial progressive tutorials then a total of 42 that take you from basic agent concepts to sophisticated multi-agent architectures.

Explore the repository →

Amazing AI Engineering Resources: LangChain

With LangChain learning resources there was a great deal of incredible documentation. These prioritized building foundational understanding, and extracting the conceptual patterns beneath the wonderful technical detail.

I began quickly, the documentation was comprehensive and architecturally rigorous, and well written, they were valuable. They're excellent first steps, in completing my journeys.

The connective tissue - resources that met me where introductory tutorials that I learned from and walked me through systematically toward production-ready implementations. This translated to concepts, architectural decisions, development attention.

My post-baccalaureate coursework in AI technology and systems provided theoretical grounding in LangGraph, RAG, CAG architectures, and hybrid systems. However, translating that foundation into production-ready code required synthesizing disparate patterns into coherent implementation strategies. This repository emerged from that synthesis process and from my genuine love of engineering and continuous learning.

What I Continued to Built: A Complete Learning Architecture

This isn't a code snippet collection. It's a structured learning path from foundational agent concepts to sophisticated multi-agent orchestration, where each tutorial builds systematically on established patterns.

Design Principles

This Repository Adheres To Three Principles:

Executable Completeness: Every tutorial runs without modification. No dependency gaps, no implementation exercises, no ambiguous instructions.
Architectural Rationale: Documentation explains not merely what the code accomplishes, but why particular patterns were selected over alternatives; the decision criteria that matter in production contexts.
Progressive Complexity: Each tutorial assumes mastery of preceding concepts, creating a deliberate pedagogical arc from basic agent instantiation to complex multi-agent coordination.

The Learning Path: From Foundations to Production

Phase I: Core Foundations (Tutorials 0-6)

The journey begins with essential concepts, but extends beyond basic functionality to address production concerns:

Tutorial 0 - Quickstart: Agent instantiation with tool integration and memory persistence. First exposure to the patterns that recur throughout the repository.

Tutorial 1 - Agents: Dynamic model selection, middleware injection, graceful error handling. The distinction between basic agents and production-ready agents becomes clear here.

Tutorial 2 - Models: Invocation methods, tool calling semantics, structured output generation. Understanding how to communicate with language models effectively.

Tutorial 3 - Messages: Conversation management, message type semantics, multimodal content handling. The data structures that enable sophisticated interactions.

Tutorial 4 - Tools: Tool creation with runtime context access. How to design tools that agents can actually use effectively.

Tutorial 5 - Memory: Short-term memory patterns, state management, conversation summarization. The architecture that enables agents to maintain context.

Tutorial 6 - LangSmith: Distributed tracing, debugging infrastructure, production monitoring. The observability layer that transforms development from guesswork into systematic refinement.

# Not just "here's an agent"—demonstrating architectural thinking
agent = create_agent(
    model=ChatOpenAI(model="gpt-4o-mini"),
    tools=[get_weather, search_web],
    memory=MemorySaver(),  # State persistence—the foundation of memory
    middleware=[error_handler, logger]  # Production concerns from day one
)

Phase II: Retrieval-Augmented Generation (Tutorials 7-10)

This sequence demonstrates architectural evolution through a carefully structured progression:

Tutorial 7: Document Loaders - Building the Knowledge Base

Foundation Work: PDF processing, text chunking strategies, embedding generation, ChromaDB storage. The infrastructure that enables retrieval.

# RecursiveCharacterTextSplitter: balancing context preservation with retrieval precision
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,      # Large enough for context
    chunk_overlap=200     # Overlap preserves semantic continuity
)

The tutorial addresses chunk size trade-offs explicitly: too small loses context, too large reduces precision. The sweet spot (800-1200 characters) emerges from production experience, not arbitrary selection.

Tutorial 8: Retrieval - Querying Strategies

Beyond basic similarity search to explore the retrieval strategy spectrum:

Similarity Search: Baseline relevance-based retrieval
Maximum Marginal Relevance (MMR): Balancing relevance with diversity to avoid redundant results
Score Thresholds: Quality control through similarity filtering
Metadata Filtering: Targeted search within document subsets

Each strategy serves specific use cases. The tutorial provides decision criteria, not just implementation options.

Tutorial 9: Two-Step RAG - Fixed Pipeline Architecture

Deterministic retrieval-then-generation pattern:

@tool
def search_knowledge_base(query: str) -> str:
    """Search the knowledge base for relevant information."""
    docs = vectorstore.similarity_search(query, k=3)
    return "\n\n".join(doc.page_content for doc in docs)

agent = create_agent(
    model="openai:gpt-4o-mini",
    tools=[search_knowledge_base],
    system_prompt="Use search_knowledge_base to find information before answering.",
    name="rag_agent"
)

Characteristics:

Predictable execution path
Consistent latency
Suitable for document-focused Q&A where context is always required

Tutorial 10: Agentic RAG - Autonomous Retrieval Decisions

Agent-Controlled Retrieval Strategy:

agent = create_agent(
    model="openai:gpt-4o-mini",
    tools=[search_documents],
    system_prompt=(
        "Use search_documents when you need specific document information. "
        "If you can answer from general knowledge, do so."
    ),
    name="agentic_rag"
)

The Critical Distinction: System Prompt Language. "Use tool when needed" versus "Use tool always" fundamentally alters agent behavior.

Phase III: Multi-Agent Orchestration (Tutorial 11)

The Supervisor Pattern Represents Architectural Sophistication:

# Specialized sub-agents
calendar_agent = create_agent(
    model="openai:gpt-4o-mini",
    tools=[],  # Production: calendar API tools
    system_prompt="You are a calendar specialist. Handle scheduling tasks."
)

email_agent = create_agent(
    model="openai:gpt-4o-mini", 
    tools=[],  # Production: email API tools
    system_prompt="You are an email specialist. Handle email tasks."
)

# Supervisor coordinates sub-agents
@tool
def schedule_event(request: str) -> str:
    """Schedule calendar events using natural language."""
    result = calendar_agent.invoke({"messages": [{"role": "user", "content": request}]})
    return result["messages"][-1].content

supervisor = create_agent(
    model="openai:gpt-4o-mini",
    tools=[schedule_event, manage_email, research_topic],
    system_prompt="You are a coordinator. Use specialized agents based on requests."
)

This architecture was implemented in my SmartFinance AI applications which provides modularity, testability, and horizontal scalability. Each sub-agent maintains focused expertise within clear domain boundaries.

When To Use Multi-Agent Systems:

Multiple distinct domains requiring specialized knowledge
Each domain has complex logic or dedicated tools
Need centralized coordination without direct user interaction per agent
System complexity justifies architectural overhead

Advanced Implementation: Context-Augmented Generation (CAG)

In addition to Retrieval Augmented Generation (RAG), this repository explores sophisticated context management through three architectural layers:

Layer 1: Model Context (Tutorial 12)

Transient modifications to model invocations which changes that affect single calls without persisting to state:

@wrap_model_call
def smart_model_selection(
    request: ModelRequest,
    handler: Callable[[ModelRequest], ModelResponse]
) -> ModelResponse:
    """Route to appropriate model based on query complexity."""

    latest_message = request.messages[-1]["content"]

    # Complexity heuristic
    is_complex = (
        len(latest_message) > 200 or
        any(word in latest_message.lower() 
            for word in ["analyze", "compare", "explain in detail"])
    )

    model = "openai:gpt-4o" if is_complex else "openai:gpt-4o-mini"
    request = request.override(model=model)
    return handler(request)

Use Cases: Dynamic system prompts, conditional tool availability, model routing based on complexity, adaptive output schemas.

Layer 2: Tool Context (Tutorial 13)

Controlling what tools access (reads) and produce (writes):

@tool
def authenticate_user(
    username: str,
    password: str,
    runtime: ToolRuntime
) -> Command:
    """Authenticate user and update session state."""

    if password == "correct":
        return Command(
            update={
                "authenticated": True,
                "username": username,
                "login_time": datetime.now().isoformat()
            },
            result="Authentication successful."
        )
    return Command(
        update={"authenticated": False},
        result="Authentication failed."
    )

Three data sources:

State: Current conversation session data
Store: Cross-conversation persistent data (user preferences, history)
Runtime Context: Static configuration (API keys, permissions)

The tool writes are persistent, they modify state permanently, unlike transient model context changes.

Layer 3: Life-cycle Context (Tutorial 14)

Intercepting the agent loop between core steps for cross-cutting concerns:

@before_model
def enforce_token_budget(state: dict) -> dict:
    """Prevent expensive calls exceeding budget."""

    tokens_used = state.get("tokens_used", 0)
    max_tokens = state.get("token_budget", 10000)

    if tokens_used >= max_tokens:
        state["messages"].append({
            "role": "assistant",
            "content": "Token budget exceeded. Please start a new conversation."
        })
        raise GraphInterrupt("Token budget exceeded", state=state)

    return state

Hook types:

before_model: Input validation, content moderation, budget enforcement
after_model: Response formatting, logging, metrics tracking
before_tools: Authorization, validation
after_tools: Error handling, result validation

The Life-cycle hooks enable automatic message summarization, content filtering, comprehensive monitoring. The cross-cutting concerns that distinguish production systems from prototypes.

Architecture:

(LangChain Docs) |

Understanding Context & Retrieval Patterns in LangChain

When building LLM applications, there are different ways to provide information (“context”) to the model. In LangChain, these patterns range from simple prompt-based context to fully agent-driven retrieval systems. Understanding when to use each approach is more important than memorizing definitions.

CAG (Static Context Injection): Context Without Retrieval

In the simplest setups, the model already has everything it needs. CAG refers to providing this information directly to the model through prompts, predefined documents, or memory - without performing any dynamic search.

This approach works best when the knowledge domain is small, stable, and well-curated, such as application rules, policies, or product documentation. Responses are fast and predictable, though updating or scaling the knowledge requires manual changes.

In Practice: This is often just a well-designed prompt or chain with static context.

from langchain.prompts import PromptTemplate
from langchain.chat_models import ChatOpenAI

# Static context provided directly to the model
static_context = """
You are an expert travel guide. 
Provide helpful recommendations for tourists in Paris.
"""

prompt = PromptTemplate(
    input_variables=["question"],
    template=static_context + "\nQuestion: {question}\nAnswer:"
)

llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

question = "What are the best hidden cafes to visit?"
answer = llm(prompt.format(question=question))
print(answer)

Two-Step RAG: Fixed Retrieval Pipeline

Two-Step RAG introduces dynamic retrieval. Before generating a response, the system always retrieves relevant documents (e.g., from a vector database) and passes them to the model.

This fixed sequence - retrieve, then generate - makes the system easy to understand and debug. However, retrieval is performed for every query, even when it may not be strictly needed, which can be inefficient for simple or mixed questions.

In Practice: This is most common starting point for RAG systems in LangChain.

from langchain.chains import RetrievalQA
from langchain.vectorstores import Chroma
from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI

# Sample documents
documents = [
    "Paris has hidden cafes in Le Marais and Montmartre...",
    "The Louvre and Musée d'Orsay are must-see museums."
]

# Create embeddings
embeddings = OpenAIEmbeddings()

# Initialize ChromaDB vector store (matches your repo)
vectorstore = Chroma.from_texts(documents, embedding=embeddings)

# Create retriever
retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

# Create RetrievalQA chain
qa_chain = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model_name="gpt-3.5-turbo"),
    retriever=retriever,
    return_source_documents=True
)

question = "Where can I find hidden cafes in Paris?"
result = qa_chain.run(question)

print(result)

Agentic RAG: Conditional Retrieval and Planning

Agentic RAG adds an agent layer that allows the system to decide whether retrieval is needed and how to perform it. The agent can reason about the query, choose tools, and orchestrate multi-step actions. The agent also reasons about the user’s request and chooses which tools to use - including retrieval.

This enables more advanced workflows, such as multi-step reasoning, tool use, and adaptive responses.

In Practice: This pattern is used when queries are complex, ambiguous, or require reasoning across multiple sources.

from langchain.agents import initialize_agent, Tool
from langchain.chat_models import ChatOpenAI
from langchain.vectorstores import Chroma
from langchain.embeddings.openai import OpenAIEmbeddings

# Sample documents
documents = ["Paris cafes guide...", "Hidden spots in Montmartre..."]

# Create embeddings
embeddings = OpenAIEmbeddings()

# Initialize Chroma vector store
vectorstore = Chroma.from_texts(documents, embedding=embeddings)
retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

# Define a retriever tool
def search_docs(query: str):
    return retriever.get_relevant_documents(query)

tools = [
    Tool(
        name="DocumentRetriever",
        func=search_docs,
        description="Fetch relevant documents for user questions"
    )
]

# Initialize agent (agent decides if retrieval is needed)
agent = initialize_agent(
    tools=tools,
    llm=ChatOpenAI(model_name="gpt-3.5-turbo"),
    agent="zero-shot-react-description",
    verbose=True
)

question = "Compare hidden cafes in Montmartre with Le Marais and recommend a day itinerary."
answer = agent.run(question)

print(answer)

How These Patterns Relate in LangChain

CAG focuses on how context is provided
RAG focuses on how context is retrieved
Agents focus on how decisions are made

LangChain supports all three patterns, allowing developers to start simple and progressively add complexity as needed. I liked that.

Important Note for Learners As I Learned Myself

CAG is used here as a descriptive term for static context injection. LangChain does not currently define CAG as a formal RAG architecture, but fully supports this pattern through prompt templates, memory, and chains.

A Simple Way to Think About It

Start with CAG when your knowledge is small and stable
Move to 2-Step RAG when you need dynamic knowledge retrieval
Use Agentic RAG when the system must reason, plan, or choose actions

At times, the best architecture is the simplest one that solves the problem.

Why This Progression in Development in AI Matters

What I learned is that LangChain is designed to support growth: you can begin with basic prompt-based systems and gradually evolve toward agent-driven architectures as your application’s needs increase.

CAG optimizes how context is supplied, RAG optimizes how context is retrieved, and agents optimize how decisions are made.

CAG → Prompt templates, memory, static documents, system context
2-Step RAG → Chains + retrievers
Agentic RAG → Agents or LangGraph with retrievers as tools

Personal Developers Note
I included CAG (Context-Augmented Generation) in this discussion because it is not usually highlighted, I learned about CAG - I feel it is an important part of LLM system design. By injecting context directly into prompts or memory, it offers simplicity, minimal latency, and predictable behavior. Showing CAG alongside 2-Step and Agentic RAG helps learners see the full spectrum of context strategies, from basic setups to complex agent-driven reasoning.

Agentic AI Implementation: My Application Smart Finance AI

These patterns aren't theoretical. Every implementation emerged from building Smart Finance AI, an Agentic AI/Multi-Agent Financial System providing:

Portfolio Management: State tracking and real-time position monitoring
Market Analysis: Sentiment processing and trend identification
Financial Planning: Goal orchestration and strategy optimization
LangGraph Coordination: Multi-agent workflows with sophisticated state management

This repository represents the technology and curriculum I successfully learned and completed and required when beginning this implementation. Each pattern addresses production challenges encountered during development, the lessons learned from building systems that actually run in production.

MY Final Thoughts Regarding LangChain - I Mean Why not LangChain Its Great!

I love engineering. I love learning. This repository exists at the intersection of both.

As a lifelong learner, I required resources that went beyond surface-level tutorials albeit remained accessible enough to build understanding systematically. The process of creating Agentic AI Application taught me that the path from learning AI concepts to implementing production systems requires more than the surface level - it requires a coherent sophisticated learning architecture.

This repository assisted me in learning, developing, creating, and building Agentic AI applications. If you're on a similar journey, passionate about engineering, committed to continuous learning, eager to build real systems - I hope it helps you as well.

Every tutorial reflects production experience. Every pattern addresses real challenges. Every architectural decision is explained with the criteria that matter when your code requirement to work reliably.

Who This Serves

This resource is for everyone - especially developers who:

Possess Python proficiency and need to learn LangChain
Have implemented basic LLM applications and seek production-grade patterns
Require understanding of RAG and CAG architectures beyond marketing materials
Require understanding of Agentic AI systems
Are building production AI systems
Are preparing for AI engineering roles requiring architectural competency
Share a passion for continuous learning and engineering excellence
Enjoy learning and development

Getting Started

git clone https://github.com/eriperspective/langchain.git
cd langchain
pip install langchain langchain-openai langchain-community langgraph pypdf langsmith
export OPENAI_API_KEY="your-api-key-here"
python 0-quickstart/quickstart_demo.py

Recommended Learning Path:

Work through tutorials 0-6 sequentially to establish foundational patterns
Complete tutorial 6 to establish debugging infrastructure
Progress through RAG sequence (7-10) to understand retrieval architectures
Study tutorial 11 for multi-agent coordination patterns
Explore advanced topics (12-41) based on specific implementation needs added for deeper learning

Technology Stack

LangChain v1.0+: Current patterns, no deprecated implementations
LangGraph: Complex agent workflow orchestration
OpenAI GPT-4o-mini: Sufficient capability, cost-optimized for learning
ChromaDB: Vector database for RAG implementations
LangSmith: Distributed tracing and debugging infrastructure

Key Repository Features
Production-Quality Code:

Comprehensive error handling and validation
Clear progress indicators and visual feedback
Both automated testing and interactive modes
Prerequisite checking and dependency verification

Architectural Emphasis:

Explicit trade-off analysis (when to use which pattern)
Decision criteria for architectural selection
Production patterns from real system implementation
Focus on why, not just how

Progressive Complexity:

Each tutorial builds on established foundations
Clear prerequisites and learning dependencies
Concepts introduced when needed, not prematurely
Natural progression from simple to sophisticated

Acknowledgments
Professor Charles Jesture at Revature who taught me Langchian and AZ Next at Arizona State University with Rob Buelow provided the theoretical foundation through post-baccalaureate coursework that enabled this amazing work. The transition from conceptual understanding to production implementation is substantial, and rigorous educational grounding proved essential.

The Future is Now & I Am Thoroughly Excited

I'll continue expanding this repository as production systems evolve. Upcoming may additions include:

Advanced error recovery patterns and circuit breaker implementations
Streaming response architectures for improved user experience
Cost optimization strategies for production-scale deployment
Additional integration examples from production systems

For developers building with these patterns, I welcome dialogue. Engineering is fundamentally collaborative, and continuous learning happens through shared experience which I enjoy.

Repository: github.com/eriperspective/langchain

This post is part of My AI engineering Journey.

Follow along for more AI Engineering Building with Eri!

What architectural challenges are you encountering in AI system development? What patterns would help you build better systems? Let's learn together.

AI Engineering and Building Systems: Reflections on a Month of AI Engineering with goose by Block

Erica — Mon, 05 Jan 2026 22:53:32 +0000

A month-long engineering journey powered with goose by Block , MCP, Anthropic's Sonnet 4.5, spatial intelligence with MediaPipe by Google, accessibility-driven UI design, and a comprehensive stack of modern AI tooling. Seventeen full-stack applications later, here's what I learned and why this workflow fundamentally transformed the way I build.

Reflections on a Month of AI Engineering with goose
Over the past month, I built seventeen full-stack applications; not prototypes, but complete, production-ready systems. Each project pushed my understanding of architecture, workflow optimization, and AI engineering capabilities beyond the previous one. I genuinely loved every moment of it. Designing interfaces, structuring state management, building MCP servers, orchestrating YAML recipes, experimenting with spatial intelligence, and refining accessibility patterns became a rhythm I craved each day. The momentum was relentless and exhilarating. Each application revealed another layer of what this workflow makes possible, and I'm walking away from this challenge more energized and inspired than when I began.

What goose Is and Why It Transformed My Workflow
goose isn't a replacement for my existing engineering workflow, it's a powerful augmentation. Goose is a comprehensive engineering environment built on the Model Context Protocol (MCP). MCP provides a structured framework for defining tools, managing state, and delivering dynamic interfaces without the traditional server infrastructure overhead. Goose brings that protocol to life in remarkable ways.

goose Desktop
A live development environment featuring real-time UI previews, auto-visualizers, comprehensive tool logs, and resource inspectors. It feels like building inside a living, breathing system that responds to your intent.

goose CLI
A command-driven interface for running MCP servers, inspecting tools, testing workflows, and debugging state. It becomes the backbone of your development loop, providing granular control over every aspect of the build process.

YAML Recipes
A lightweight automation layer that enables you to chain tools, execute multi-step workflows, and define repeatable processes without writing additional code. It's automation that feels intuitive rather than cumbersome.

MCP Auto Visualizers
These instantly transform structured tool outputs into visual interfaces - tables, trees, HTML, JSON, UI fragments. No extra configuration required. The visualization happens automatically, letting you focus on the logic rather than the presentation layer.

Anthropic's Sonnet 4.5 and Goose API Integration
Throughout this challenge, I leveraged Sonnet 4.5 within goose to generate code, refactor architecture, build UI components, draft documentation, validate accessibility patterns, and prototype spatial intelligence workflows. The synergy between Sonnet 4.5's reasoning capabilities and goose's structured environment created a development experience that genuinely felt like pair programming with an engineer who comprehends the entire system architecture.

Why Goose Is a Game-Changer for AI Engineering
Let me be clear: goose fundamentally changed how I approach building software. This isn't hyperbole - it's the reality of working with a tool that eliminates friction at every level of the development process. Before goose, I was constantly context-switching between editors, terminals, browsers, documentation, and testing environments. Each switch broke my flow, interrupted my thinking, and slowed down the feedback loop that's essential to creative problem-solving.
goose eliminates that fragmentation entirely

The Power of Unified Context
What makes goose exceptional is how it maintains unified context across every aspect of development. When I'm building an MCP server, goose isn't just running my code, it's visualizing my data structures in real-time, logging every tool interaction with full transparency, and letting me inspect state at any moment without breaking stride. The Desktop environment shows me exactly what's happening inside my application as it happens. There's no "build, refresh, check, debug" cycle. There's just immediate, continuous feedback.

This might sound like a minor convenience, but the impact is profound. When you can see your changes reflected instantly, when you can inspect tool outputs without switching windows, when you can debug state without adding console logs and restarting processes, you stay in flow. I feel flow is where the best engineering happens.

MCP: The Protocol That Changes Everything
The Model Context Protocol is the foundation that makes goose's magic possible, and it deserves recognition as a genuinely innovative approach to building AI-powered applications. MCP standardizes how tools communicate, how state is managed, and how interfaces are rendered. Instead of building custom APIs, managing server deployments, and coordinating complex microservice architectures, MCP gives you a clean, declarative way to define what your application does.

This isn't just simpler, it's fundamentally more expressive. With MCP servers, I can define complex tool chains, manage stateful workflows, and deliver dynamic UIs without the overhead that typically bogs down development. And because goose is built around MCP, everything just works together seamlessly. Tools talk to each other. State persists correctly. Visualizations appear automatically. The protocol eliminates an entire category of integration problems that usually consume hours of debugging time.

Speed Without Sacrificing Quality
One of the biggest misconceptions about rapid development tools is that speed comes at the cost of quality. Goose proves that's false. The seventeen applications I built this month aren't prototypes or proof-of-concepts; they're production-quality systems with proper architecture, comprehensive accessibility, and thoughtful design. Goose didn't make me cut corners; it removed the tedious barriers that usually slow down good engineering.

When YAML recipes let me automate multi-step workflows, I'm not avoiding the complexity. I'm managing it more intelligently. When auto-visualizers render my data structures instantly, I'm not skipping the work of understanding my outputs. I'm seeing them more clearly. When Sonnet 4.5 integration helps me refactor code or generate documentation, I'm not replacing my engineering judgment. I'm augmenting it with AI that understands context and intent.
This is what modern AI engineering should feel like: powerful, expressive, and fast without compromising on craft.

A Development Experience That Feels Alive
The best way I can describe working with goose is that it feels alive. The environment responds to you. It anticipates what you need. It makes the invisible visible. When you're building with goose, you're not fighting your tools; you're collaborating with an environment that's designed to amplify your capabilities.

I've used a lot of development environments over the years. Some are powerful but clunky. Others are elegant but limited. Goose is the first tool I've encountered that manages to be both powerful and delightful. It handles complexity gracefully while staying out of your way. It gives you control without overwhelming you with configuration. It's opinionated about the right things and flexible about everything else.

The Future of Development Is Here
goose represents a fundamental shift in what's possible with AI-assisted development. It's not about replacing developers - it's about giving developers superpowers. It's about removing the friction that separates an idea from its implementation. It's about making the development process so smooth, so intuitive, so responsive that building software becomes as creative and expressive as any other art form.

This month proved to me that we're at an inflection point. The tools exist. The protocols exist. The AI models exist. What we're seeing with goose is all of these pieces coming together in a way that feels inevitable in hindsight but revolutionary in practice.

The new agentic group created by major tech companies, including OpenAI, Block, and Anthropic are the co-founding stewards, with support from other platinum members including Google, Microsoft, Amazon Web Services (AWS), Bloomberg, and Cloudflare is called the Agentic AI Foundation (AAIF). The foundation was launched under the umbrella of the Linux Foundation in December 2025. If you're serious about AI engineering, if you want to build faster without sacrificing quality, if you want a development experience that feels empowering rather than exhausting; like many other great AI tools goose is a wonderful addition. It's not just a tool. It's a glimpse into the how we'll all be building software in the very near future with all these amazing technologies.

[(https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation#:~:text=Summary,across%20different%20repositories%20and%20toolchains.)]

MediaPipe: Building Spatial Intelligence into Applications
One of the most exciting aspects of this challenge was integrating MediaPipe by Google into my workflow. MediaPipe is Google's open-source framework for building multimodal machine learning pipelines. It provides pre-trained models for hand tracking, pose detection, face mesh recognition, object detection, and gesture recognition - all running efficiently in the browser or on device.

What makes MediaPipe particularly powerful is its accessibility. You don't need extensive ML expertise or server-side infrastructure to implement sophisticated computer vision features. The framework handles the complexity of real-time processing, letting developers focus on creating meaningful interactions.

Why MediaPipe Matters for Modern Applications
In my projects, I used MediaPipe to build spatial intelligence features that transform how users interact with applications. Hand tracking enables gesture-based controls without physical input devices. Pose detection opens possibilities for fitness tracking, accessibility tools, and interactive experiences. Face mesh recognition powers AR filters, emotion detection, and attention tracking.

These aren't just novel features - they represent a fundamental shift in human-computer interaction. As we move toward more natural, intuitive interfaces, spatial intelligence becomes essential. MediaPipe makes this technology accessible to developers at every level, democratizing what was once only available to large organizations with significant ML resources.
Practical Applications I Built

Throughout the challenge, I integrated MediaPipe into several applications to explore gesture-based navigation, hands-free controls for accessibility, spatial UI interactions, and pose-based fitness tracking interfaces. Each implementation revealed new possibilities for creating more inclusive and intuitive user experiences.
The combination of MediaPipe with goose's rapid development environment meant I could prototype, test, and refine these spatial features quickly. What might have taken weeks in a traditional workflow became achievable in hours.

How This Work Applies to Real-World Engineering

The systems I built this month weren't abstract experiments - they map directly to real engineering challenges. MCP servers function like lightweight microservices. Dynamic HTML rendering mirrors internal dashboards and admin tools. YAML recipes reflect production automation pipelines. Sonnet 4.5 became my AI engineering partner for code generation, architecture decisions, and technical documentation. The accessibility work aligns with production UI standards and WCAG compliance. Even the spatial intelligence prototypes connect to emerging AR and multimodal interfaces that are reshaping how we interact with technology.

goose assisted in expanding my workflow, giving me a faster and more expressive way to build the same caliber of systems that real engineering teams depend on daily.

A Month of Technologies, Patterns, and Systems

Across seventeen projects, I worked extensively with:

MCP servers with custom tool layers, state engines, and rendering pipelines
Semantic HTML, WCAG guidelines, and ARIA accessibility patterns for inclusive design
Glassmorphism, gradients, and motion-aware UI for modern, polished interfaces
YAML automation recipes for workflow orchestration
MediaPipe and spatial intelligence for multimodal interactions
JavaScript and TypeScript full-stack patterns for robust application architecture
Organizational systems including architecture diagrams, planning documents, and reusable pattern libraries

Each project built on the foundation of the last. The workflow became progressively more structured, more expressive, and more enjoyable with every iteration.

Accessibility: Building for Everyone
Accessibility isn't just a feature I implement; it's a core value that shapes every decision I make as an engineer. Throughout this challenge, I prioritized WCAG (Web Content Accessibility Guidelines) and ARIA (Accessible Rich Internet Applications) standards in every single application I built. This wasn't an afterthought or a checklist item. It was foundational to my design process.

Why Accessibility Matters to Me
Technology should empower everyone, regardless of their abilities. When we build inaccessible applications, we're not just creating inconvenience -we're actively excluding people from participating in digital spaces. That's unacceptable to me. Accessibility means someone with a visual impairment can navigate my interface using a screen reader. It means someone with motor difficulties can use keyboard navigation instead of precise mouse movements. It means someone with cognitive differences can understand my interface without confusion.

The beautiful thing about accessible design is that it makes applications better for everyone. Clear semantic HTML improves SEO and code maintainability. Proper ARIA labels enhance usability across all devices. Keyboard navigation benefits power users. High contrast ratios help people in bright sunlight or low-light environments. When we design for accessibility, we design for flexibility and resilience.

WCAG and ARIA in Practice
In every application, I implemented:

Semantic HTML structure using proper heading hierarchies, landmark regions, and meaningful element choices
ARIA labels and roles to provide context for screen readers and assistive technologies
Keyboard navigation patterns ensuring every interactive element is reachable and operable without a mouse
Color contrast ratios meeting WCAG AA standards (4.5:1 for normal text, 3:1 for large text)
Focus indicators that are clearly visible and never removed without providing an alternative
Alt text for images that provides meaningful descriptions, not just decorative labels
Error identification and suggestions that help users understand and correct mistakes
Responsive layouts that work across screen sizes and zoom levels without breaking functionality

The Real-World Impact
Accessibility isn't theoretical. It changes lives. I've seen firsthand how proper ARIA implementation allows someone using a screen reader to complete a task in seconds instead of minutes. I've watched keyboard navigation enable people with motor impairments to use interfaces that would otherwise be impossible for them. I've received feedback from users with cognitive differences who appreciated clear, consistent navigation patterns.

Every time I write semantic HTML, every time I add an ARIA label, every time I test keyboard navigation. I'm making a choice to include rather than exclude. And that matters deeply to me.

Moving Forward
As I continue building, accessibility remains non-negotiable. The tools are here. The guidelines are clear. The impact is measurable. There's no excuse for building inaccessible applications, and I'm committed to raising the standard in every project I touch. Because technology should work for everyone—and it's our responsibility as engineers to make that happen.

Closing Reflection
While this marks the final chapter of the Advent of AI challenge and the conclusion of this particular phase, it represents only the continuation of an AI engineering journey I'm committed to pursuing every single day. The tools are here, the architecture is proven, and the momentum is undeniable. Now it's time to discover just how far this approach can scale.

What's Next for this AI Engineer

This month of intensive engineering was a foundation, not a finish line. Seventeen full-stack systems later, I'm stepping into the next phase of my AI engineering journey with unprecedented clarity and structural understanding. The projects I built during this challenge were deliberately diverse: Full-stack applications deployed, MCP servers, UI engines, automation workflows, spatial intelligence prototypes, accessibility-driven interfaces, and organizational systems that now fundamentally shape how I approach software development.

The next step is taking this work beyond the challenge and into the broader AI engineering community. I'll be attending the Microsoft AI Tour conference, continuing to refine and evolve my workflow, and exploring how these patterns scale into larger, production-grade systems. My goal is to keep pushing the boundaries of AI engineering and AI-assisted development deeper MCP integrations, richer UI architectures, more sophisticated spatial and multimodal experiments, and a more intentional approach to building tools that feel both cohesive and genuinely human-centered.

This challenge may be complete, albeit my AI engineering journey will continue. I couldn't be more excited about what comes next.

This post is part of my AI engineering journey.

Follow along for more AI Engineering Building with Eri!

AI Engineering: Advent of AI with goose Day 17 - Building MCP Server & Wishlist AI Application

Erica — Mon, 05 Jan 2026 20:29:50 +0000

Day 17: Building a Complete MCP Server & Wishlist Application with MCP and goose

For the final day of this Advent of AI journey, I wanted to build something that brought together everything I explored over the past sixteen days: UI engineering, state management, automation, accessibility, and full‑stack architecture. Instead of simply creating an application that runs inside an MCP environment, I built the MCP server itself. This meant defining the tool layer, managing the application state, and engineering a complete HTML rendering pipeline that outputs a fully interactive UI inside goose.

The result is a complete Wishlist Application powered by a custom MCP server. It exposes its own tools, maintains its own logic, and renders its own interface dynamically on every interaction. This project represents the culmination of a month of daily engineering with goose and demonstrates how expressive the Model Context Protocol becomes when the server and the UI are designed together.

What an MCP Server

The Model Context Protocol defines a structured way for external tools, applications, and services to communicate with an AI model. An MCP server exposes a set of capabilities through a predictable interface, allowing the client to call tools, request resources, and receive structured responses. Instead of building a traditional web server, an MCP server focuses on defining clear operations, returning machine-readable results, and maintaining state in a controlled environment. This makes it ideal for interactive applications that need to update their UI or logic in response to user actions.

For this my project, I created a custom MCP server that manages the entire Wishlist Application. It defines the full set of wish operations, maintains application state in memory, and generates the UI dynamically on every tool call. The server uses the official MCP TypeScript SDK and communicates with the client over stdio, which keeps the development loop simple and predictable. Each tool updates the state, triggers a fresh HTML render, and returns both text and UI resources to the client. This architecture allowed me to build a complete, interactive application entirely inside the MCP environment.

Overview
The Wishlist Application is not just a UI running inside MCP. It is a full MCP server that defines its own capabilities, manages its own state, and generates its own interface. The server exposes a complete tool suite for adding, removing, granting, filtering, and managing wishes. Each tool call triggers a full UI regeneration through a custom HTML rendering engine, allowing the interface to update in real time inside goose.

The architecture mirrors a full-stack web application: a state layer, a rendering layer, a tool layer, and a transport layer. The difference is that everything is delivered through the Model Context Protocol rather than a traditional HTTP server. This approach keeps the system modular, predictable, and easy to extend while still providing a polished, interactive experience.

My Wishlist Application is a fully stateful MCP server that exposes a complete UI through MCP-UI resources. It supports:

Adding, removing, and granting wishes
Secret wish handling
Category filtering
Dark and light mode
An admin panel with statistics
Dynamic HTML generation
A full CSS-driven interface
Real-time UI updates on every tool call The server uses the official MCP TypeScript SDK and integrates with the MCP-UI rendering system to deliver a complete visual experience inside the client.

Technology Stack

My application is built on a modern, modular stack:

MCP Server: TypeScript (using @modelcontextprotocol/sdk)
Transport Layer: stdio (standard input/output)
UI Delivery: MCP Resources (HTML rendering)
Rendering Engine: Dynamic HTML generation with inline/external CSS
State Management: In-memory TypeScript objects
Tool Layer: Custom MCP tools for CRUD operations (add, remove, update, filter wishes)
Client Environment: goose Desktop
AI Model: Claude Sonnet 4.5

This stack allows the application to behave like a full web app while running entirely inside an MCP environment.

Features

Core Functionality

Add, remove, and grant wishes
Toggle secret status
Filter by category or secret
Toggle dark mode
Toggle admin panel
Sparkle effect for granted wishes
Full UI rebuild on every interaction

UI System
The UI is generated dynamically using:

A complete HTML template
A CSS file loaded at runtime
Category icons
Secret indicators
Glassmorphism cards
Animated background orbs
A responsive layout The server returns the UI as a direct HTML resource, allowing the client to render it inline.

MCP Tools
The server exposes a full suite of tools:

view_wishes
add_wish
grant_wish
remove_wish
set_secret
set_filter
toggle_dark_mode
toggle_admin_panel
sparkle_granted Each tool updates the application state and returns both a text response and a fresh HTML UI resource.

Project Structure

wishlist-mcp/
├── JS/
│   ├── index.js            # Main MCP server (tools, state, HTML rendering)
│   ├── generate-html.js    # Standalone HTML generator for UI testing
│   └── index.js.backup     # Previous server version (reference only)
│
├── lib/
│   ├── render.ts           # HTML rendering engine
│   ├── state.ts            # Wish state and operations
│   └── commands.ts         # Natural-language command parsing
│
├── images/                 # UI icons and visual assets (magic, joy, snow, fairy, lock)
│
├── style.css               # Full UI styling (glassmorphism, layout, palette)
│
├── response.json           # Example MCP response (kept for debugging)
│
├── package.json            # Project metadata and dependencies
├── package-lock.json       # Dependency lockfile
│
└── node_modules/           # Installed dependencies (present in real projects)

This structure separates UI, state, rendering, and server logic for clarity and maintainability.

Technical Architecture Diagram

                           ┌──────────────────────────────────────────┐
                         │        Wishlist MCP Server               │
                         │        (JS/index.js entrypoint)          │
                         └──────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │              MCP Tool Layer                   │
                   │  add, remove, grant, filter, toggle, sparkle │
                   │  (Defined in JS/index.js)                    │
                   └──────────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │            Application State Layer            │
                   │  lib/state.ts                                 │
                   │  wishes, filters, dark mode, admin panel      │
                   └──────────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │              Rendering Engine                 │
                   │  lib/render.ts                                │
                   │  HTML builder + CSS + icons + UI logic        │
                   └──────────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │           Command Parsing Layer               │
                   │  lib/commands.ts                              │
                   │  Natural-language interpretation               │
                   └──────────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │               MCP-UI Resource                │
                   │ directHtml delivered to goose Desktop         │
                   └──────────────────────────────────────────────┘

This architecture: a full-stack web application, albeit delivered entirely through MCP.

Development Notes
The server is built using the official MCP TypeScript SDK, with Stdio transport for local integration. Each tool call triggers a full UI regeneration, ensuring the interface always reflects the current state. The rendering engine composes HTML, CSS, and UI assets into a complete interface that can be displayed by any MCP-UI capable client.

Accessibility Techniques Used
My Wishlist Application incorporates accessibility directly into its UI rendering layer. Icon‑only controls use explicit aria-label attributes to ensure they are announced correctly by screen readers, and all interactive elements are implemented using semantic HTML such as header, h1, and button. Images include descriptive alt text when meaningful, and decorative assets can be marked with empty alt attributes to avoid unnecessary verbosity.

The interface is fully keyboard accessible because all actions are exposed through native button elements rather than custom div-based controls. The CSS supports readable contrast in both light and dark modes, and the layout remains stable without relying on motion-heavy effects. These techniques collectively align with WCAG principles and ensure that the UI remains usable across a wide range of assistive technologies.

Accessibility is always considered throughout the UI design. The HTML structure uses semantic elements, descriptive alt text, and predictable interaction patterns. The CSS avoids motion-heavy effects and maintains readable contrast across both light and dark modes.

The backend logic is cleanly separated from the UI layer. State operations, filtering, and wish manipulation are handled in dedicated functions, while the rendering engine focuses solely on producing the visual interface. This separation makes the application maintainable and extensible.

My Final Thoughts
Day 17 brought the entire Advent of AI journey full circle. I started this month building small utilities and CLI workflows, and I ended it by engineering a complete MCP application with a dynamic UI, a full tool suite, and a rendering pipeline. This project represents the intersection of everything I explored: front-end design, backend logic, accessibility, automation, and protocol-driven architecture.

What I appreciate most is how natural it felt to build a complete system on top of the Model Context Protocol. I was not just creating an application inside an MCP environment. I built the server itself, defined the tool interface, implemented the state management layer, and engineered the entire UI rendering pipeline. The protocol’s structure encouraged a clean separation of concerns, and goose made the development loop fast and expressive.

This final challenge was more than a conclusion. It demonstrated how far this architecture can be pushed when the server, the UI, and the interaction model are all designed together. A month of AI engineering produced seventeen distinct systems, each building on the last. The Wishlist Application is a fitting finale: a complete, interactive, architecturally coherent MCP server with a fully custom UI, polished, interactive, and architecturally complete.

Although this marks the final chapter of the Advent of AI challenge and the end of this phase, it is simply the continuation of my AI engineering journey in which I plan to keep learning & building daily; which I truly enjoy!

This post is part of my Advent of AI journey - AI Engineering: Advent of AI with goose Day 17 of AI engineering challenges.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 16 - An Immersive Countdown AI Application

Erica — Mon, 05 Jan 2026 18:18:41 +0000

Day 16: Perspective Countdown - A Modern, Immersive Countdown AI Application

For Day 16, I shifted from backend automation and knowledge‑engineering systems into a fully interactive full-stack experience. The goal was to build a professional, dynamic countdown application that feels modern, polished, and immersive. This project combined real‑time functionality, glassmorphism UI, spatially aware animations, and accessibility‑driven design into a cohesive Next.js application.

The result is Perspective Countdown: a responsive, visually rich countdown experience built with contemporary web technologies and AI engineered with the same precision and structure I have applied throughout this challenge.

Overview
Perspective Countdown provides a real‑time countdown to December 1, 2026 at 10:00 AM. The interface blends aesthetic design with functional clarity, featuring:

Real‑time countdown tiles
Rotating fun facts
Email signup with validation
Social sharing integration
A responsive navigation bar
A realistic snowfall animation rendered on canvas The application is engineered for performance, accessibility, and long‑term maintainability.

Technology Stack
This project uses a modern, production‑ready stack:

Framework: Next.js 15 with App Router
Language: TypeScript
Styling: Tailwind CSS with custom animation layers
Fonts: Parisienne for headings, Inter for UI text
Runtime: Node.js This stack supports server components, client‑side interactivity, and a clean separation of concerns across the application.

Features

Core Functionality

Real‑time countdown updated every second
Rotating informational facts with timed transitions
Email signup with client‑side validation and persistence
Social sharing via Web Share API with fallback logic
Responsive navigation bar with scroll‑to‑section behavior

Design Elements

Glassmorphism UI with frosted transparency
Custom gradient background using a defined brand palette
Realistic snowfall animation using canvas and requestAnimationFrame
Smooth hover transitions and micro‑interactions
Mobile‑first responsive layout
WCAG‑aligned accessibility features This palette supports the glassmorphism aesthetic while maintaining contrast ratios suitable for accessibility.

Project Structure

countdown-ai/
├── app/
│   ├── api/
│   │   ├── subscribe/
│   │   │   └── route.ts        # POST endpoint for email signup
│   │   ├── share/
│   │   │   └── route.ts        # Optional API for server-side share logging
│   │   └── events/
│   │       └── route.ts        # Example backend endpoint for event metadata
│   ├── globals.css             # Global styles and animations
│   ├── layout.tsx              # Root layout component
│   └── page.tsx                # Main page component
│
├── components/
│   ├── BottomNav.tsx           # Bottom navigation bar
│   ├── Countdown.tsx           # Real-time countdown display
│   ├── EmailSignup.tsx         # Email subscription form (client)
│   ├── FunFactsRotator.tsx     # Rotating facts component
│   ├── Hero.tsx                # Hero section with icon
│   └── Snowfall.tsx            # Canvas-based snow animation
│
├── data/
│   └── funFacts.ts             # Array of rotating facts
│
├── lib/
│   ├── time.ts                 # Time calculation utilities
│   ├── email.ts                # Server-side email validation and processing
│   ├── db.ts                   # Database connection (Supabase, Prisma, or custom)
│   └── logger.ts               # Server-side logging utilities
│
├── prisma/                     # Optional ORM schema
│   └── schema.prisma
│
├── public/                     # Static assets
│
└── scripts/
    └── seed.ts                 # Database seeding script

The structure follows Next.js 15 conventions with clear separation between UI components, data, and utility logic.

My Key Components

Countdown: Implements a real‑time countdown using setInterval with cleanup. The component updates every second and renders time segments in glassmorphic tiles.

Hero: Displays an animated hourglass icon with subtle motion. Typography uses the Parisienne font for a distinctive visual identity.

FunFactsRotator: Cycles through facts every seven seconds with fade transitions. Uses aria-live="polite" to ensure screen readers receive updates without interruption. This was actually really fun to implement.

EmailSignup: Provides client‑side validation, local persistence, and a placeholder for backend integration. Designed for future expansion into EmailJS, Supabase, or a custom API.

Snowfall: A canvas‑based animation simulating realistic snowfall. Uses 100 snowflakes with varying velocities and sizes. Optimized with requestAnimationFrame for smooth performance.

BottomNav: A fixed navigation bar with scroll‑to‑section behavior and integrated social sharing.

Accessibility
I wanted to take a moment to highlight Accessibility. My application incorporates accessibility from the foundation which is dear to my heart:

Semantic HTML with proper landmarks
ARIA labels and live regions for dynamic content
Keyboard navigation with visible focus states
Sufficient color contrast
Screen reader compatibility This ensures the experience is usable across a wide range of devices and assistive technologies.

Browser Compatibility

Chrome
Firefox
Safari
Edge The application includes Web Share API support with clipboard fallback and uses CSS backdrop‑filter for glassmorphism where supported.

Performance Considerations

Efficient use of React hooks
Canvas animation optimized with requestAnimationFrame
Minimal re‑renders through isolated state
Lightweight dependency footprint The result is a smooth, responsive experience across devices.

Enhancements

Backend API integration for email storage
Dark mode with preference persistence
Calendar event download functionality
Analytics instrumentation
Progressive Web App support These additions extended the application into a fully featured event‑driven platform.

Development Notes
The application follows Next.js 15 conventions with the App Router architecture. All interactive components are marked as client components using the use client directive. Styling is handled through Tailwind CSS utilities with custom CSS for animations and transitions.

Accessibility was integrated from the beginning rather than added later. Components use semantic HTML, ARIA attributes, and predictable keyboard interactions to ensure the interface remains usable across assistive technologies.

The backend layer is implemented through Next.js API routes, providing a clean separation between client components and server logic. Server utilities handle validation, logging, and optional database integration, allowing the application to scale into a fully featured full‑stack system without restructuring the core architecture.

My Final Thoughts
Day 16 was a return to front‑end AI engineering, but with the mindset I have developed throughout this challenge: clarity, structure, and maintainability. Building a visually rich, interactive countdown application required balancing aesthetics with performance and accessibility. The result is a polished, modern interface that feels alive without sacrificing technical rigor.

This project reminded me how much I enjoy crafting user experiences that are both beautiful and engineered with intention. It also reinforced how well goose integrates into a full‑stack workflow, from ideation to implementation.

Day 16 continues the momentum, and the next challenges will build on this foundation.

This post is part of my Advent of AI journey - AI Engineering: Advent of AI with goose Day 16 of AI engineering challenges.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 15 - AI Multi Platform Recipe System

Erica — Mon, 22 Dec 2025 23:49:45 +0000

Day 15: Building a Multi Platform Social Media Campaign System with goose Recipes

The marketing team needed a coordinated social media push across Instagram, Twitter X, and Facebook. Each platform required a different tone, structure, and content style.

This challenge introduced sub recipes in goose. Instead of writing three separate pieces of content by hand, the goal was to build a reusable automation system. One input. Three platform specific outputs. A single orchestrator recipe coordinating the entire workflow.

The Challenge: Automate Multi Platform Content Generation

The task was to create a four recipe system:

instagram-post.yaml
twitter-thread.yaml
facebook-event.yaml
social-campaign.yaml (main orchestrator)

Each recipe needed to accept the same core parameters:

event_name
event_date
event_description
target_audience
call_to_action

The orchestrator recipe needed to call all three sub recipes and produce a complete campaign package.

The Social Media Campaign System
The completed system generates:

A fashionable, high impact Instagram caption
A concise, professional five tweet Twitter X thread
A warm, family oriented Facebook event description

All content is produced from a single input set and saved to a unified output file. Each recipe was validated, structured with proper YAML frontmatter, and tailored to the communication style of its platform.

Technical Architecture Diagram

Below is a generated text based diagram showing how the recipe system is structured.

                         ┌──────────────────────────────────────────┐
                         │        Social Campaign System             │
                         └──────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │           Main Orchestrator Recipe            │
                   │            social-campaign.yaml               │
                   └──────────────────────────────────────────────┘
                                        │
        ┌──────────────────────────────────────────────────────────────────────────┐
        │                                                                          │
        ▼                                                                          ▼
┌──────────────────────────┐                                      ┌──────────────────────────┐
│ instagram-post.yaml       │                                      │ twitter-thread.yaml       │
│ Platform specific caption │                                      │ Multi tweet thread        │
└──────────────────────────┘                                      └──────────────────────────┘
                                        │
                                        ▼
                              ┌──────────────────────────┐
                              │ facebook-event.yaml       │
                              │ Long form event content   │
                              └──────────────────────────┘

This architecture allows the orchestrator to call each sub recipe independently, aggregate the results, and produce a complete campaign package.

Technical Stack

Below is my stack that powers this system.

Layer	Technology	Purpose
Runtime	goose CLI with Recipes extension	Executes recipes and sub recipes
Orchestration	social-campaign.yaml	Coordinates multi recipe execution
Sub Recipes	instagram, twitter, facebook YAML files	Platform specific content generation
Parameters	YAML schema with required fields	Ensures consistent input across all platforms
Output	Markdown file	Unified campaign package
Reasoning	goose LLM engine	Generates platform appropriate content

This is a recipe based automation stack designed for repeatable, scalable content generation.

Platform Outputs
The system generated three fully formatted outputs for the Magic Night of Lights and Ice Sculpture Unveiling. Each output reflects the tone and expectations of its platform.

Instagram A high impact caption with strategic hashtags and a polished, visual forward tone.

Twitter X A five tweet thread under 280 characters per tweet, structured for clarity and shareability.

Facebook A long form event description written for families and community oriented audiences.

My Final Thoughts
Day 15 shifted the focus from knowledge engineering to workflow automation. Recipes appear simple at first glance, but orchestrating multiple sub recipes into a cohesive system requires architectural thinking. What stood out in this challenge was the clarity that comes from building reusable automation. Instead of writing content three separate times, I now have a system that will work for every future event with no additional effort.

This is engineering that scales. This is engineering that saves teams time.
This is exactly where goose excels. It rewards structure, clarity, and repeatability.

Day 15 encouraged me to think like a systems designer rather than a content generator, and that shift will matter in the challenges ahead.

This post is part of my Advent of AI journey - AI Engineering: Advent of AI with goose Day 15 of AI engineering challenges.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 14 - Complete Operations System

Erica — Mon, 22 Dec 2025 23:06:10 +0000

Day 14: Building a Complete Operations Knowledge System with goose Skills

The Winter Festival succeeded because of the expertise of its team. Every department had developed its own workflows, escalation paths, and operational knowledge, but none of it was documented in a way that could scale. With three neighboring towns requesting help to run their own festivals, the Director needed a system that could capture this expertise and make it reusable.

This challenge introduced goose Skills, a mechanism for encoding domain knowledge into structured, discoverable, and portable expertise. Instead of producing a static manual, the goal was to build a living operational system that goose can load and apply automatically whenever a coordinator needs guidance.

The Challenge: Capture Operational Knowledge as a Skill System

The mission was to create a festival‑operations skill that consolidates the knowledge of four core team members:

Customer experience workflows
Security and vendor protocols
Lost and found procedures
Marketing and communications guidelines

The skill needed to be actionable, structured, and discoverable by goose. It also required supporting files such as checklists, templates, decision trees, and scripts to form a complete operational system.

Understanding goose Skills
A goose Skill is a markdown file with YAML frontmatter that teaches goose a domain. Skills are automatically discovered at session start and loaded when relevant. They differ from recipes because they provide knowledge rather than execute tasks.

Skills include:

Core knowledge (SKILL.md)
Checklists
Templates
Decision trees
Scripts
Recipes for generating new skills

This allows a skill to function as a modular knowledge system rather than a single document.

The Full Skills Architecture
I did not build a single skill.

I built a multi‑skill operational knowledge architecture with layered expertise, reusable components, and cross‑skill interoperability.

Below is my complete directory structure:

+---eriperspective-ai-engineering
|       debugging-checklist.md
|       decision-trees.md
|       engineering-style.md
|       problem-analysis.md
|       SKILL.md
|       
+---festival-operations
|   |   decision-trees.md
|   |   SKILL.md
|   |   
|   +---checklists
|   |       closing.md
|   |       opening.md
|   |       quick-reference.md
|   |       
|   +---recipes
|   |       skill-generator.md
|   |       
|   +---scripts
|   |       cleanup.sh
|   |       
|   \---templates
|           incident-report.md
|           
+---lost-and-found
|       SKILL.md
|       
+---marketing-communications
|       SKILL.md
|       
+---security-protocols
|       SKILL.md
|       
\---volunteer-management
        SKILL.md

Six independent skills, each representing a domain of festival operations or engineering practice.

Technical Architecture Diagram

                         ┌──────────────────────────────────────────┐
                         │        goose Skills Knowledge Base        │
                         └──────────────────────────────────────────┘
                                        │
                                        ▼
                   ┌──────────────────────────────────────────────┐
                   │        Multi‑Skill Operational System         │
                   └──────────────────────────────────────────────┘
                                        │
        ┌──────────────────────────────────────────────────────────────────────────┐
        │                                                                          │
        ▼                                                                          ▼
┌──────────────────────────┐                                      ┌──────────────────────────┐
│  eriperspective-ai-       │                                      │   festival-operations    │
│  engineering (Personal OS)│                                      │   (Primary Domain Skill) │
└──────────────────────────┘                                      └──────────────────────────┘
        │                                                                          │
        │                                                                          │
        ▼                                                                          ▼
┌──────────────────────────┐                                      ┌──────────────────────────┐
│ Debugging workflows       │                                      │ Customer experience       │
│ Decision trees            │                                      │ Security protocols        │
│ Engineering style         │                                      │ Vendor management         │
│ Problem analysis          │                                      │ Lost and found workflows  │
└──────────────────────────┘                                      │ Marketing communications   │
                                                                  └──────────────────────────┘
                                        │
                                        ▼
                     ┌─────────────────────────────────────────────┐
                     │     Department‑Specific Operational Skills   │
                     └─────────────────────────────────────────────┘
                                        │
        ┌──────────────────────┬────────────────────────┬────────────────────────┬──────────────────────┐
        ▼                      ▼                        ▼                        ▼
┌──────────────────┐   ┌──────────────────┐     ┌──────────────────┐     ┌──────────────────┐
│ lost-and-found    │   │ marketing-       │     │ security-         │     │ volunteer-        │
│ SKILL.md          │   │ communications   │     │ protocols         │     │ management        │
└──────────────────┘   └──────────────────┘     └──────────────────┘     └──────────────────┘

This diagram reflects the actual structure: a layered, modular knowledge system with a personal engineering OS, a primary operational skill, and multiple departmental sub‑skills.

Achievement Summary

All four challenge tiers were completed:
I progressed through every Goose challenge tier: Beginner, Intermediate, Advanced, and Ultimate, building a full multi‑skill system and completing my personal eripersoective AI Engineering OS skill at the highest level. This skill functions consistently in both Goose CLI and Goose Desktop environments.

Beginner Level Completed
Created a new Goose skill with proper YAML frontmatter
Added multiple operational sections
Added supporting files like quick‑reference checklists
Formatted the skill for clarity
Successfully tested the skill in Goose

Intermediate Level Completed
Built multiple related skills (one per department)
Added templates and structured supporting files
Included decision trees for complex scenarios
Ensured the skills were compatible across Goose environments

Advanced Level Completed
Created skills that reference each other
Added runnable supporting scripts
Built a skill‑generator recipe
Added a skill‑testing checklist to validate quality

Ultimate Level Completed
Built the eriperspective AI Engineering OS skill
Captured my engineering philosophy, learning style, UI aesthetic, and immersive‑tech interests
Added decision trees, checklists, recipes, and templates
Created a complete personal engineering OS that Goose can use to think and reason like mechecklists.
Created Erica’s Engineering OS, a complete personal operating system capturing engineering philosophy, workflows, debugging processes, and decision‑making patterns.

This is a full enterprise‑grade knowledge system.

Erica’s Engineering OS
As part of the Ultimate Challenge, you built a complete engineering operating system containing:

Debugging workflows
Problem analysis frameworks
Decision trees
Engineering style guidelines
Learning philosophy

This OS defines a consistent engineering identity and provides a reusable framework for problem solving and decision making.

goose Skills are just files on disk its knowledge‑engineering stack that supports discovery, loading, and execution inside goose.

Technical Stack for the Goose Skills System

goose Runtime Environment
This is the core execution layer.

goose CLI (v1.17.0+)
goose Desktop (optional, compatible)
Skills extension enabled
Developer extension enabled

This environment is responsible for:

Skill discovery
Skill loading
Contextual relevance matching
Applying skill knowledge to user queries

Filesystem‑Based Skill Architecture
Skills are stored as structured directories:

~/.config/goose/skills/
./.goose/skills/

This provides:

Namespacing
Priority‑based skill resolution
Cross‑skill interoperability
Portability across machines

Markdown + YAML Knowledge Format
Every skill uses:

YAML frontmatter for metadata
Markdown for structured knowledge
Subdirectories for modular components

This stack enables:

Human‑readable documentation
Machine‑interpretable metadata
Extensibility through supporting files

Skill Submodules
My system uses multiple submodules:

checklists/
templates/
recipes/
scripts/
decision‑trees.md
debugging‑checklist.md

These act as:

Operational modules
Reusable components
Knowledge primitives
Execution helpers (scripts)

Shell Script Execution Layer
Included runnable scripts such as:

cleanup.sh

This introduces:

POSIX shell compatibility
Script execution via goose Developer extension
Automated maintenance workflows

Cross‑Skill Knowledge Graph
My architecture forms a knowledge graph, not a flat set of files.

Skills reference each other implicitly through:

Shared domains
Overlapping terminology
Goose’s relevance engine

This allows:

Multi‑skill reasoning
Department‑specific overrides
Hierarchical expertise

Tech Stack

Layer	Technology	Purpose
Runtime	goose CLI + Skills extension	Skill discovery and execution
Storage	Filesystem directories	Namespaced skill organization
Format	Markdown + YAML	Human and machine readable knowledge
Modules	Checklists, templates, scripts, decision trees	Operational components
Execution	Shell scripts	Automation and maintenance
Reasoning	goose relevance engine	Contextual skill loading

My Final Thoughts
Day 14 produced a complete operational knowledge system built on goose Skills. The festival‑operations skill captures the expertise of the entire team and makes it accessible to any future coordinator. The supporting files, decision trees, templates, and scripts transform the skill into a practical, scalable operational system.

Day 14: Completed Operational knowledge: Captured. Skill ecosystem: Fully established.

This post is part of my Advent of AI journey, AI Engineering: Advent of AI with goose Day 14.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 13 - AI Scheduling Accessible Application Terminal Integration

Erica — Mon, 22 Dec 2025 21:29:34 +0000

Day 13: Building a Complete Scheduling System with Terminal Integration

Today’s challenge focused on transforming scattered staff availability notes into a fully functional scheduling application. Instead of relying on manual organization or spreadsheets, the goal was to use goose’s terminal integration to guide the entire process. With goose active in the terminal, the AI could observe commands, understand context, and provide real‑time assistance while building the system.

This challenge demonstrated how terminal integration enables a natural workflow: staying inside the terminal, running commands, inspecting files, and receiving contextual AI guidance without switching tools.

Author's Note
WCAG accessibility is essential to my engineering approach because it ensures that every interface I build can be used reliably by people with diverse abilities and assistive technologies. I prioritize semantic structure, keyboard navigation, contrast standards, and ARIA roles because accessible design is not optional; it is a core requirement for professional, inclusive systems. Building with WCAG in mind strengthens usability for everyone and guarantees that the applications I create remain functional, equitable, and future‑proof.

The Challenge: Turn Napkin Notes into a Scheduling System
Provided a set of unstructured staff notes. The mission was to:

Use goose in the terminal
Organize all staff availability, constraints, and skills
Identify scheduling conflicts
Build a complete three‑day festival schedule
Produce a professional scheduling website
Ensure the system is usable by the entire festival team

The final result needed to be a real application, not just a data file.

Terminal Integration with goose
The key skill for Day 13 was understanding how goose’s terminal integration works. Unlike goose run, @ goose can see terminal history and infer context from recent commands.

For example:

cat staff_notes.txt
@goose "who can work Wednesday"

There is no need to reference the file explicitly. @goose already knows what you are working on. This creates a fluid, real‑time development workflow where the AI acts as a technical partner inside the terminal.

The Scheduling Application
The final deliverable was a complete, production‑ready scheduling application contained in a single HTML file. It includes a full design system, staff management tools, shift creation, conflict detection, and persistent data storage.

Design System

Exact color variables from designinstruction.html
Gradient backgrounds using the primary palette (#6366f1 to #8b5cf6)
Glassmorphism surfaces with blur and transparency
Animated background with rotating radial gradients
Inter font typography
Professional dark mode aesthetic (#0a0a0f)
Smooth animations including fadeInUp, rotate, and pulse
Shimmer hover effects on buttons

Core Functionality

Staff Management

Add, edit, and delete staff
Track availability by day and hour
Manage skills and constraints
Visual staff cards with structured details

Schedule Builder

Create, edit, and delete shifts
Seven‑day tabbed schedule view
Time slot management
Assignment descriptions
Table‑based layout for clarity

Conflict Detection

Real‑time validation during shift creation
Availability checks
Overlapping shift detection
Time constraint validation
Visual warnings with detailed explanations

Data Persistence

Automatic saving to localStorage
JSON export
Load sample data
Print‑friendly layout

Dashboard and Statistics

Live staff count
Total shifts
Conflict count
Coverage percentage
Conflict alerts with detailed breakdown
Dynamic updates across all views

Accessibility
The application adheres to WCAG guidelines:

Semantic HTML5
ARIA roles for dialogs, tablists, and tabpanels
Keyboard navigation including ESC to close modals
Screen reader support
High‑contrast color system
Visible focus indicators

Responsive Design

Mobile‑first layout
Breakpoints at 968px and 640px
Collapsible mobile navigation
Touch‑friendly controls
Stacked layouts on small screens

Technical Features

Fully self‑contained single HTML file
No build process required
No external dependencies beyond CDN fonts and icons
Complete CRUD operations in JavaScript
Persistent data via localStorage
Clean print layout

Final Thoughts
The scheduling application is fully dynamic, responsive, accessible, and ready for real use. It replaces Marcus’s scattered notes with a structured, interactive system that the entire festival team can rely on.

Day 13 demonstrated how terminal integration with goose can accelerate real‑world engineering tasks, turning unstructured information into a complete operational tool.

Day 13: Completed Scheduling system: Delivered. Festival operations: Organized.

This post is part of my Advent of AI journey, AI Engineering: Advent of AI with goose Day 13.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 12 - MCP Orchestrated Intelligent Multi‑agent Reasoning

Erica — Mon, 22 Dec 2025 20:53:22 +0000

Day 12: The Festival Mascot Crisis

This was the perfect use case for the Council of Mine MCP extension. Nine AI personas, each with a distinct reasoning style, debating and voting democratically.

This challenge focused on using MCP sampling to orchestrate intelligent multi‑agent reasoning inside goose.

What MCP:
MCP, the Model Context Protocol, is a framework that allows tools and extensions to communicate with AI models in a structured, reliable way. Instead of returning static data, an MCP extension can request reasoning from the AI model, incorporate that reasoning into its own logic, and return an intelligent, context‑aware result. This enables extensions to behave like specialized agents that can analyze information, generate multiple perspectives, and support complex decision workflows. MCP sampling builds on this by allowing an extension to create several distinct AI viewpoints, compare them, and synthesize a final recommendation.

The Challenge: Convene the Council
The mission was to install the Council of Mine extension, initiate a debate on the mascot topic, gather nine perspectives, run a democratic vote, and synthesize the final decision. The goal was to demonstrate how MCP sampling enables extensions to request AI reasoning, generate multiple viewpoints, and return structured analysis rather than raw data.

MCP Sampling Overview
MCP sampling allows extensions to request help from goose’s AI model. Instead of returning static data, the extension can ask the model to analyze, interpret, or generate multiple perspectives.

Normal extension flow:
You → goose → Extension → Returns data → goose interprets

MCP sampling flow:
You → goose → Extension → Extension requests AI reasoning

Extension receives AI output → Returns intelligent analysis → goose

This enables extensions to behave like intelligent specialists rather than simple data providers.

Why MCP Sampling Matters

Extensions can generate multiple AI personas
Distributed reasoning becomes possible
Domain expertise can be simulated
Complex decisions can be debated democratically
The extension becomes an orchestrator of AI perspectives

Real‑World Applications

Multi‑perspective analysis
Intelligent documentation
Context‑aware search
Database analysis
Multi‑expert code review

Submissions and Debates Completed A total of six debates were conducted across simple and complex topics. All required tasks for Day 12 were completed.
This challenge demonstrated how Council of Mine leverages MCP sampling to create 9 distinct AI personas that debate topics and vote democratically, producing nuanced recommendations superior to single-perspective analysis.

Debates Conducted: 6 Total
Simple Topics (4):
Mascot Selection → Winner: The Systems Thinker → Penguin
Mascot Naming → Winner: The Pragmatist → Test 2-3 finalists with community
Sidekick Decision → Winners: Visionary & Systems Thinker → Pilot program
Cookie Selection → Winners: Mediator & Visionary → Curated selection with gingerbread anchor

Complex Topics (2):
Festival Expansion → Winner: The Pragmatist → Add 1 day first, measure, then decide
Tradition vs Innovation → Winners: Analyst & Pragmatist → 60/40 ratio with data validation

Most Influential Council Members:

The Pragmatist: 11 votes (dominates complex decisions)
The Systems Thinker: 10 votes (scales with complexity)
The Analyst: 5 votes (data-driven validation)

Universal Patterns:
Evidence beats ideology every time
Testing before commitment is universal
Accessibility matters in all decisions
60/40 tradition/innovation ratio emerged naturally
Incremental approaches consistently win

MCP Sampling Power:
9 distinct AI personas with unique reasoning
Democratic voting reveals collective wisdom
Synthesis combines best of all perspectives
Superior to single-perspective analysis

Complex decision-making requires:
Systems-level thinking to understand interconnections
Pragmatic approaches to manage risk
Evidence-based validation before commitment
Incremental implementation for testing assumptions
Accessibility considerations for inclusive outcomes

These members consistently shaped outcomes, especially in complex decision spaces.

Universal Patterns Observed

Evidence consistently outperformed ideology
Testing before commitment was preferred
Accessibility considerations appeared in every decision
A natural sixty to forty tradition to innovation ratio emerged
Incremental approaches were favored over large‑scale changes

MCP Sampling Capabilities Demonstrated

The Council of Mine extension showcased the strengths of MCP sampling:

Nine distinct AI personas with unique reasoning styles
Democratic voting that reveals collective intelligence
Synthesis that merges the strongest elements of each viewpoint
Superior decision quality compared to single‑perspective analysis

Requirements for Complex Decision Making

The council demonstrated that effective complex decisions require:

Systems‑level thinking to understand interdependencies
Pragmatic approaches to reduce risk
Evidence‑based validation before committing resources
Incremental implementation to test assumptions
Accessibility considerations to ensure inclusive outcomes

Across all debates, the council consistently showed that the strongest decisions emerge from:

Recognizing multiple valid perspectives
Testing assumptions before scaling
Balancing innovation with proven methods
Preserving core values while enabling evolution
Using data to guide decisions rather than justify them

Visualizations Created
Interactive Visualizations Created

Council Voting Power (Bar Chart)
Shows total votes received by each council member
The Pragmatist leads with 11 votes
Systems Thinker close behind with 10 votes
Reveals influence hierarchy across all debates

Decision Characteristics (Radar Chart)
Compares simple vs complex topic patterns
Complex topics score 95% on evidence-based approaches
Complex topics heavily favor systems thinking
Shows how complexity shifts decision-making priorities

Challenge Flow (Sankey Diagram)
Visualizes flow from challenge levels through debates to outcomes
Demonstrates how beginner work feeds intermediate analysis
Shows convergence on evidence-based outcomes and testing frameworks
Illustrates incremental approach emerging from advanced challenges

Topic & Strategy Distribution (Donut Charts)
67% simple topics, 33% complex topics
Pragmatic strategies dominate at 35%
Systems-based and data-driven approaches folllow
Balanced strategies round out decision-making

Member Influence Trajectory (Line Chart)
Tracks how council member votes change across debates
Pragmatist influence surges in complex topics
Systems Thinker maintains steady high influence
Visionary shows consistent moderate influence

Outcomes Treemap
Visual hierarchy of all achievements
Color-coded by type (Decision, Process, Strategy, Analysis, Output)
Size represents relative importance
Shows balanced completion across all levels

Insights
This challenge demonstrated how multi‑agent reasoning can outperform single‑agent decision making. MCP sampling enables extensions to orchestrate multiple AI perspectives, debate complex topics, and produce structured, evidence‑driven recommendations. The Council of Mine extension is a practical example of distributed AI reasoning applied to real decision workflows.

My Final Thoughts
Day 12 showcased the power of MCP sampling and multi‑persona reasoning. By convening the Council of Mine, I transformed a chaotic debate into a structured, democratic decision process. The result was a clear, evidence‑driven recommendation supported by nine distinct reasoning styles.

Day 12: Completed Mascot crisis: Resolved. Council decision: Selected.

This post is part of my Advent of AI journey, AI Engineering: Advent of AI with goose Day 12.

Follow along for more AI Engineering Adventures with Eri!

AI Engineering: Advent of AI with goose Day 11 - Photo AI Filter Accessible Application - Spatial Intelligence & Subagents

Erica — Mon, 22 Dec 2025 19:55:15 +0000

Day 11: The Photo Booth AI Application - Real‑Time Filters, Spatial Intelligence & Subagents

What if you could build a full AR‑style photo booth - camera access, face detection, real‑time filters, capture, download, and QR sharing - all in a single day? And what if you didn’t have to build it alone?

That’s exactly what Day 11 challenged me to do.

Using goose subagents, I built a complete Fun House Photo Booth web app with festive filters, MediaPipe face tracking, mobile support, and a full capture pipeline. It feels like having a small engineering team working in parallel - because that’s exactly what subagents simulate.

Day 11: Photo Booth AI Application 📸

The Challenge: Build a Real-Time Filter App in One Day
The festival director wanted a magical selfie booth:

Open on your phone
See yourself with fun filters
Filters track your face
Switch between effects
Capture the photo
Download it
Share it

This is where subagents shine.

Enter: The Fun House Photo Booth (Built with Subagents)

I split the work into specialized subagents - just like a real dev team:

Subagent 1 - Core App Builder

Built the HTML/CSS/JS structure
Implemented camera access
Created the live video preview
Added capture + download
Made everything mobile‑responsive

Subagent 2 - Filter Engineer

Integrated MediaPipe Face Landmarker
Implemented 468‑point face mesh
Built the real‑time filter system
Anchored filters to specific landmarks
Added filter switching

Optional Subagents I Added

Stylist - polished the UI (FilterSense branding)
Documentation Writer - created usage notes
Performance Optimizer - ensured smooth tracking

Subagents let me parallelize the work and keep the build clean and modular.

Tech Stack

goose Subagents task orchestration
Sonnet 4.5 by Anthropic
HTML/CSS/JS core app
MediaPipe Face Landmarker local spatial intelligence
Canvas API rendering filters + mesh
SessionStorage storing captured images
QR workflow for sharing
Mobile‑first UI responsive layout

No backend. No server. Everything runs locally.

My Experience (From Camera to AR Filters)
I started by building a clean UI - a glowing camera icon, a “FilterSense” title, and an Enter button. Once inside, the app activates the camera, loads MediaPipe, and begins tracking the user’s face in real time.

Then the fun begins:

Select a filter
Watch it attach to your face
Move, tilt, smile - it follows
Capture the moment
Download or share

The entire experience feels like a lightweight AR app running directly in the browser.

What My Application Does

Opens the camera instantly
Tracks the face using MediaPipe
Renders a 468‑point mesh
Applies filters anchored to landmarks
Lets users switch filters
Captures a clean photo
Stores it safely
Redirects to an export page
Supports download + QR sharing
Works smoothly on mobile

It’s a complete photo booth system.

Spatial Intelligence (MediaPipe Face Landmarker)

One of the most advanced parts of this build is the spatial intelligence. Instead of sending video frames to a server, the entire face‑tracking pipeline runs in the browser using MediaPipe’s Face Landmarker.

Why this matters

Real‑time performance
Low latency
Offline capability
Privacy‑preserving
No external compute required

How it works
I load the FaceLandmarker and FilesetResolver modules, which return:

468 face landmarks
3D positional data
Stable tracking across movement
Mesh topology
Mesh can be removed at any time These landmarks drive the entire filter system.

Mesh Rendering
I implemented a full tessellation renderer using the MediaPipe FACEMESH_TESSELATION array. It draws:

glowing neon nodes
connecting edges
animated mesh movement

This visualizes the underlying AI in real time.

Filter Anchoring
Each filter is mapped to a specific landmark:

'Crown': { landmark: 10, offsetY: -60 }
'Beard': { landmark: 152, offsetY: 40 }
'Reindeer Eyelashes': { landmark: 159, offsetY: -10 }

This ensures perfect alignment as the user moves.

Clean Capture Pipeline
To avoid tainted canvases, I built a safe capture flow:

Create a fresh canvas
Draw the video frame
Draw only the mesh (no external PNGs)
Export as PNG
Store in sessionStorage
Redirect to export page

This guarantees consistent captures across browsers.

Technical Highlights
The app uses structured subagents to divide responsibilities cleanly. The Core App Builder handles UI, camera access, capture, and mobile responsiveness. The Filter Engineer manages MediaPipe initialization, mesh rendering, and filter anchoring. The system uses a clean canvas pipeline to avoid CORS issues and ensures safe PNG export.

Spatial intelligence runs entirely on‑device, enabling real‑time AR effects without external compute. Filters follow the user’s face with sub‑pixel accuracy thanks to landmark‑driven positioning. The UI is fully responsive, and the workflow supports capture, download, and QR‑based sharing.

Insights

Subagents feel like having a real dev team although it was myself, my code and my design
MediaPipe’s local inference is incredibly powerful
Clean capture pipelines matter
Spatial intelligence unlocks AR‑level experiences
Declarative workflows scale beautifully
Mobile‑first design is essential for real‑world use

Powered By

goose by Block powered by Sonnet 4.5 by Anthropic
MediaPipe by Google
HTML/CSS/JS
My own design + engineering workflow

My Final Thoughts
This was one of the most fun builds so far. Using subagents, I created a full AR‑style photo booth with real‑time filters, spatial intelligence, and a polished UI all running locally in the browser. The combination of MediaPipe, canvas rendering, and goose orchestration made it possible to build something that feels magical.

Day 11: Solved Filter Sense Photo Booth: Delivered. Festival magic: Activated.

This post is part of my Advent of AI journey AI Engineering: Advent of AI with goose Day 11.

Follow along for more AI adventures with Eri!