AI Systems and Agentic Architecture: Applied Technical Practice

At Lab829, we use the Lab to explore, design, and build AI systems directly: MCP servers that integrate with Claude, multi-region cloud architecture for AI-assisted decisioning, and an edge-deployed conversational AI platform. The four projects below span pre-design architecture and working software, and show how we approach hands-on AI system design and implementation.

1. Fintech Risk Assessment Architecture (AWS Pre-Design)

What it is: The pre-design architecture for a multi-region fintech product involving credit-risk and fraud-assessment workflows. The work explored viable AWS service boundaries, failure modes, security controls, and orchestration patterns before committing the product to a detailed implementation design.

What it covers:

• Regional serverless APIs using Amazon API Gateway and AWS Lambda, with AWS Step Functions Standard Workflows considered for durable, auditable decision processes. Reliability depends on explicit retry and error-handling policies and idempotent Lambda handlers, not orchestration alone.
• Amazon SageMaker AI as the appropriate boundary for deploying trained credit-risk or fraud models, with SageMaker Clarify considered for bias analysis and per-prediction explanations.
• Amazon Bedrock for assistive work with unstructured information, such as document interpretation or analyst summaries, rather than as the authoritative source of a credit decision. Where retrieval-augmented generation is useful, Bedrock Knowledge Bases supports purpose-built vector stores; Amazon Kendra is an intelligent search service, not a vector database.
• Independent regional stacks using Regional API Gateway endpoints, Route 53 latency-based routing, and health checks for an active-active pattern. Geolocation routing remains a separate option when traffic must follow geographic or business rules rather than lowest-latency selection.
• Security and operational controls including AWS WAF geographic matching, IAM least-privilege roles, CloudWatch observability, and CloudTrail audit history. These are architectural controls that support a compliance program, not compliance guarantees by themselves.
• A hybrid workflow model: Step Functions for stateful processes that require explicit sequencing and execution history, and Amazon EventBridge for loosely coupled events, routing, and fan-out. The services solve different problems and can be used together.

Why it matters: Pre-design is where consequential product assumptions should be challenged before they become expensive implementation constraints. This work shows how we reason through orchestration, event-driven boundaries, model explainability, regional routing, resilience, and security before moving a fintech product into detailed technical design, without disclosing its proprietary product logic.

2. Wealth Finder: Claude Desktop MCP Server for Personal Finance

What it is: An open-source MCP server that connects Claude Desktop to a Supabase-backed personal finance dataset, exposing ten distinct tools for account summaries, spending analysis, bill tracking, subscription audits, and interest paid summaries.

What it covers:

• A working Model Context Protocol server (TypeScript) with full Supabase integration, including schema design, row-level security policies, and database migrations.
• Ten purpose-built tools (get_account_summary, get_spending_by_category, get_bills_due, set_spending_alert, get_subscriptions_audit, and others) that let an AI assistant query and act on financial data through a structured, auditable interface rather than open-ended access.
• End-to-end setup documentation, an automated seeding script, and a test suite at the tool level.
• Explicit scope discipline: the README states directly that this is a local demo environment, not production financial infrastructure, with investment execution intentionally out of scope.

Why it matters: This demonstrates a core skill behind the MCP integrations we build in the Lab: defining a small, well-scoped set of tools that give an AI assistant structured access to financial records in a demonstration environment. The boundaries are easier to inspect and test than open-ended data access. You can clone the MCP server and explore the implementation.

3. Agent Live Platform: Edge-Deployed AI Chat Widget

What it is: A working conversational AI platform developed and operated in the Lab. Agent Live ran with Supabase Edge Functions and in Google Cloud, with PostgreSQL retrieval, multilingual response support, usage tracking, and application logs.

What it covers:

• An edge-only backend architecture, with runtime calls routed through Supabase Edge Functions (chat, cached-questions, health, log-interaction, question-click, generate-embeddings), removing the need for a traditional always-on backend server.
• For non-cached questions, the platform attempts semantic retrieval with PostgreSQL, pgvector, and OpenAI embeddings before generating a response, with priority-based retrieval available as a fallback.
• Database security work including row-level security across public tables, restricted service-role access, a hardened search path for the vector-match function, and PostgreSQL extensions isolated outside the public schema.
• Usage and interaction logging that supported operational review while the product was deployed.
• Database-managed system prompts that could be updated without rebuilding the application. Later review identified prompt history, evaluation, and rollback as areas that should receive a more explicit change-control workflow.
• Frontend unit tests, Supabase Edge Function tests, and a Playwright end-to-end suite. Later hardening work added per-route rate-limit guardrails and stricter CORS behavior, while also exposing the need for distributed rate limiting, deployment-level header verification, and reliable test-traffic isolation.

Why it matters: Agent Live was a production-ready product for its intended scope, not a static demonstration. Planning, implementation, deployment, retrieval, logging, security, and later hardening all informed the work. That experience helps us identify the infrastructure and operating decisions that should be made early when adapting the approach for another product.

4. Obsidian Job Search MCP Server

What it is: A job-search assistant built in the Lab that connects Claude to an Obsidian workspace. It helps turn a growing collection of saved roles, notes, applications, and decisions into a manageable daily workflow.

What it covers:

• Save interesting roles throughout the day and review them together when it is time to make decisions.
• Compare opportunities against a personal search profile so recommendations stay connected to role preferences, location, compensation, and career goals.
• Keep applications, interviews, passed opportunities, and rejected roles organized without maintaining another spreadsheet.
• Remember previously reviewed postings and flag duplicates, reducing repeated work across job boards and recruiting platforms.
• Support an active job search containing more than 160 tracked roles, giving the workflow a real-world test well beyond a small demonstration.

Why it matters: A serious job search can quickly become a second job. If you are saving dozens of roles, losing track of decisions, or struggling to review opportunities consistently, this kind of personal AI workflow can help. Get in touch if you would like help setting up or adapting a job-search assistant around the way you work.

What these four Lab projects show together

These projects started with different needs: exploring a fintech product before committing to a build, giving an AI assistant controlled access to financial data, creating a useful chat experience, and making a demanding job search easier to manage. The common thread is practical AI that works within clear boundaries and supports a real decision or workflow.

That is the kind of work we explore at Lab829. We can help shape an early AI product idea, identify where automation would genuinely save time, design a safer integration with existing data, or build a focused prototype that your team can test before making a larger investment.

If one of these projects resembles a problem you are trying to solve, explore AI and machine learning integrations or start a conversation with us. The best place to begin is often not with a large AI transformation program, but with one useful workflow that can be understood, tested, and improved.