Build in Public: Medical Validation System (deco & Afya)

Rafael Crespo

November 26, 2025

Note: The workshop recording below is in Portuguese.

In this special "Build in Public" session, we partnered with Afya’s innovation team to tackle a real-world challenge: automating the validation of medical credentials.

In just over an hour, we demonstrated how to go from a blank canvas to a functional MVP using the deco, leveraging AI Agents, MCPs (Model Context Protocol), and automated workflows to verify doctor information—a process that is typically manual and time-consuming.

play_arrow

Watch the video

Workshop Summary

Here is a breakdown of how the solution was architected and built during the session:

The Challenge

Afya needed a way to streamline the onboarding of doctors. The goal was to create a system where a doctor could submit their data (Name, CPF, CRM, Diploma), and the system would automatically validate these credentials against public databases and ensure compliance, replacing manual checks.

The Primitives

We utilized the core building blocks of deco to build the app:

• AI Agents: Used to interact with the user (the doctor) via a conversational interface to collect required data.
• Database (SQLite): Automatically generated by the AI to store doctor profiles and validation statuses.
• Tools (MCPs): Modular functions that allow the AI to interact with external worlds. We used tools for database CRUD operations, Brasil API (for CPF/CNPJ validation), and Gemini Pro Vision (for analyzing diploma images).
• Workflows: The logic layer that orchestrates the validation steps (e.g., "Check CPF" -> "Check CRM" -> "Analyze Image" -> "Update Database").
• Views: A custom UI dashboard generated by AI to allow administrators to view the list of doctors and trigger validation workflows.

The Architecture & Workflow

The application follows a streamlined flow:

1. Data Collection: A doctor interacts with an AI Agent via a chat interface. The Agent collects necessary fields (Name, CRM, UF, Diploma URL) and saves them to the database using a Create Doctor Tool.
2. Visual Dashboard: An administrator accesses a generated Dashboard View that lists all registered doctors with their current status.
3. Automated Validation: The admin clicks a "Validate" button. This triggers a specific Workflow.
4. Execution: The workflow runs multiple checks in parallel:

• Validates format and existence of CPF/CNPJ via API.
  • Analyzes the uploaded Diploma image using Computer Vision to detect if it is a generic template or a valid document.

5. Result: The system saves the validation report back to the database and updates the UI, flagging any suspicious data (e.g., "Diploma looks like a Freepik template").

The Prompt

Everything started with a single, well-structured prompt designed to generate the Product Requirements Document (PRD). This prompt guided the AI to understand the business rules, data schemas, and the "Agentic" behavior required.

Here is the full prompt used to kickstart the application:

Create a PRD 1. Overview Don’t overengineer it, make it simple The system allows doctors to register, have their data stored, and later validated through internal rules and external API checks. An agent collects the data without fabricating any information and saves everything to the database. A dashboard allows reviewers to view registered doctors, validate their data, and approve/reject profiles. 2. Goals * Allow doctors to submit their professional data. * Store information with consistency and security. * Use an agent to collect information and save it to the database without hallucinations. * Display a general list of registered doctors. * Allow manual validation triggered by a button (“Validate”). * Allow approval or rejection after analysis. 3. User Flow (MVP) 1. The doctor talks to the Agent and sends their data. 2. The agent uses the Create Doctor Tool to save the data to the database. 3. The agent confirms that the data has been received and is under review. 4. The reviewer opens the Dashboard and sees the list of doctors. 5. The reviewer clicks Validate → the system runs validations. 6. The system generates a validation report. 7. The reviewer clicks Approve or Reject. 4. Required Information Name (required) CPF (required) CNPJ (required) CRM (required) CRM-UF (required) Diploma file (URL) (required) RQE (non required) Specialty (non required) 5. Validation Rules CRM * Check character length. * Ensure it contains only numbers. * Validate UF (SP, RJ, MG, etc.). RQE (optional) * Check length. * Validate numeric format. Diploma * Validate that a URL was provided. * Validate that the file is not a template. CNPJ (via DataJud MCP) * Confirm existence. * Check if active. * Check if not under judicial process. * Check if it belongs to the medical sector. CPF (via Brazil API MCP) * Validate format. * Fetch official data. * Confirm that the CPF name matches the CRM name (via CFM). 6. System Components (MVP) Tools * Create Doctor Tool: Saves data received from the form or agent. * Get Doctors List Tool: Returns registered doctors. * Update Doctor Tool: Updates validation results and status (approve/reject). * Validate CPF Tool * Validate CNPJ Tool * Validate CRM Tool * Validate Doctor Workflow: Will run complete validations. Will runs validate CPF, cnpj, crm tool 7. Database Schema (MVP) doctors table ID - UUID Name - String CPF - String CNPJ - String CRM - String CRM_UF - String Diploma_URL - String RQE - String? If not send save a empty string specialty - String? If not send save a empty string Validations table id - UUID DoctorID - doctor_id Status - string (pending, reproved, accepted) validation_report - string 8. AI Agent Requirements Responsibilities * Talk with the doctor and collect data. * Do not invent any information. * Save using the Create Doctor Tool. * Confirm that the information is under analysis. Limitations * Does not perform validations at this stage. 9. Dashboard (MVP) List View * Name * CRM + UF * CPF * Status * Validate button * View Details button Validation * When clicking Validate: * Runs workflows with validation rules * Generates validation report, e.g.: "{ crm: valid, crm_uf: valid, cpf: valid, cpf_name_match: invalid, cnpj: valid, diploma: valid, rqe: not_provided }” Actions * Approve * Reject 10. Status Lifecycle pending → in_review → validated → approved/rejected

Live Debugging

One of the most valuable aspects of "Build in Public" is seeing that AI development isn't magic—it's still software engineering. After creating the validation workflow, the team hit a snag: the validation was running, but the dashboard wasn't updating.

• The Bug: By checking the logs, the team realized the AI Agent had successfully run the validation logic but simply "forgot" to include a step to save the results back to the database.
• The Fix: Instead of rewriting code manually, Ventura instructed the agent: "Now save the result in the validations table".
• The Result: The agent corrected the workflow, created a Validations Create tool, and successfully stored the data. This highlighted the platform's ability to self-correct through natural language iteration.

Computer Vision

Once the debugging was complete, the true power of the multi-modal agent shined. We tested the system with a fake doctor profile using a generic certificate image found online.

The Gemini Pro Vision tool analyzed the uploaded diploma URL and returned a verdict: "Suspect: Generic template". The AI explicitly noted that the diploma appeared to be a design from "Freepik," successfully flagging a potential fraud without any manual rule-coding.

The Strategy

The workshop concluded with a critical discussion on how to take this from a "Vibe Coding" session to a secure, enterprise-grade application for a company like Afya.

• The "MCP Mesh": We introduced the concept of an organizational "Mesh." Instead of business users building everything from scratch, technical teams (Context Engineers) expose secure APIs and data via MCPs. Business users (AI Builders) then use these pre-approved blocks to build tools.
• Governance & Git-Based Deploy: Unlike low-code tools that trap you in a "black box," the solution shown is Git-based. This means every change created by the AI is versioned, reviewable via Pull Requests, and capable of instant rollback—meeting the strict security requirements of a large healthcare enterprise.

Final Verdict

The session wrapped up with the Afya team validating the approach. They highlighted that while they have internal data lakes and teams, the bottleneck is often the agility to build frontend interfaces and workflows for specific business units.

"I was already a fan, now I'm even more of a fan... It solves many pains regarding agility and MVP development prepared for deep integration with our ecosystem." — Eduardo Moura, Afya