AI connected to operations
Organize information, tasks and next actions in a usable application.
The operations platform demonstrates dashboards, pipeline, proposals and assistance with bounded tools.
Hi, I'm Cesar
Applied AI Engineer and solutions architecture. I structure applications with language models, agents and automation, connecting business problems to integrations, execution rules and system validation.My YouTube channelCM
Videos on YouTube
Recent publications from my channel.
Como Implementar IA na Sua Empresa: O Que Falta Além do ChatGPT
Watch on YouTube
Assista ao video completo
Watch on YouTube
Camada de integrações #automaçãoempresarial #dashboardempresarial #integraçãodesistemas
Watch on YouTube
Como Centralizar os Dados da Sua Empresa em um Único Dashboard
Watch on YouTube
Video 1 of 4
Applied AI engineering
My work connects product experience to the architecture behind AI.
- I organize components, authorized information sources, model tools and execution rules.
- This includes deciding where AI can interpret and where deterministic checks must control permissions, data and effects.
The case studies cover an operations platform with AI assistance and an agent runtime with human approval and resumption.
- I led solution structure, architectural decisions, component implementation and validation.
- The public demo shows product behavior; the briefings and evidence explain the engineering.
From business need to system
Three approaches to applied AI illustrated by the projects below.
Agents with execution rules
Structure intention, proposal, review and execution.
Approval belongs to an exact proposal: changes, revoked sources and incompatible context stop execution.
Integrations with explicit boundaries
Define external reads, response validation and failure handling.
The reviewed connectors implement capability negotiation, timeouts, bounded retries and pagination checks.
Projects
Applied AI engineering projects
LLMs, agents, integrations and data, with contracts, tests and security controls. Open a card to examine architecture and evidence.
Illustrative project animations. The demonstration uses synthetic data. Briefings explain implementation scope and local validation.
CASE STUDY / 01
Operations platform with AI
Demo online · AI controls validated locally
Problem
Operational decisions depend on connecting contacts, tasks, proposals and pipeline stages.
AI assistance must access these records within user permissions and allowed operations.
Solution
An operations application with dashboards, pipeline, tasks, proposals and indicators, alongside an LLM assistance backend.
The independent demo exposes product organization without customer data or services.
- 01
Product and interface
Dashboards, pipeline, tasks and proposals
- 02
API and context
Identity, permissions and validated input
- 03
Model and tools
Interpretation, tool calling and limits
The interface calls the API.
- The server establishes user and organization context, prepares information and exposes bounded tools.
- Tool requests are validated and authorized; results are sanitized before returning to the conversation.
Engineering decision
Semantic tools instead of model-generated unrestricted SQL.
Access remains a server responsibility and can be exercised with controlled provider responses.
My responsibility
Solution structure, module and product organization, assistance and data-access decisions, implementation coordination, validation scenarios and the independent demonstration.
Demonstrable outcome
A navigable synthetic product and locally verified chat, context, tool and authorization controls.
Usage contracts distinguish unknown cost from zero and handle recoverable provider failures.
Stage and next validation
Lexical memory queries and migrations are implemented; real PostgreSQL validation is pending.
- External integrations are simulated in the demo.
- Integrated database/provider operation is not certified.
CASE STUDY / 02
Agent and automation platform
Components validated locally · integration in development
Problem
An agent may use an unsuitable source, execute a changed proposal or resume a task twice.
These boundaries require architectural controls beyond model instructions.
Solution
An agent runtime separating request, proposal, authorization, review and execution.
MCP resource and REST connectors operate within explicit conditions for continuing or stopping.
- 01
Proposal and source
Authorized context and required capability
- 02
Approval and state
Exact-version review and transition rules
- 03
Execution and resumption
Ownership and completion records
The server binds a source to the organization and required capability.
- Human approval authorizes the exact proposal version.
- Execution advances through states and resumption checks task ownership.
Engineering decision
Deny ambiguous sources and invalidate approval after proposal changes.
Completion is recorded before success is announced; ownership and resumption logic are tested with in-memory stores.
My responsibility
Execution boundaries, states, approval rules, component and connector implementation coordination and failure validation.
Separate observability work covers evidence integrity and telemetry minimization.
Demonstrable outcome
Local scenarios verify revoked sources, incompatible approval, altered proposals, concurrent resumption, protocol negotiation and read failures.
They do not establish database locks or operational recovery.
Stage and next validation
Tests use simulated providers, transports and stores.
- Real persistence, external integration and continuous operation are not certified.
- OTLP components remain in development with separate local validation.
Capabilities
Capabilities explained through system behavior. Each area connects a concrete decision to a project and its evidence scope.
LLM application architecture
Separate interface, API, context, model and tools.
- The model interprets; the system controls operations, permissions and execution limits.
- OpenRouter integration follows a chat and tool-calling contract.
In the project:
A semantic tool request is validated and authorized before sanitized information returns to model context.
Agents, states and human approval
Orchestrate proposals and actions through explicit states.
Human review applies to a particular organization, proposal version and fingerprint.
In the project:
Resumption checks execution ownership and records completion before announcing success.
Local scenarios use simulated models and stores.
APIs, MCP resources and integrations
Contracts for external information access.
The MCP client negotiates capabilities and lists resources; REST/Microsoft Graph reads constrain origin and document scope.
In the project:
Timeouts, bounded retries, circuit breakers and pagination checks are exercised with injected transports.
Data, memory and context engineering
Authorized context, metric contracts and lexical memory retrieval.
Missing information must remain distinguishable from valid values.
In the project:
PostgreSQL queries and migrations are implemented.
Real database validation is pending; this is lexical retrieval, not a vector-search claim.
Security and execution governance
Server-derived permissions, source-to-organization binding and sanitization.
Negative scenarios test when assisted actions must be refused.
In the project:
Missing, revoked or ambiguous sources deny access.
Evidence covers local controls, not a comprehensive security audit.
Observability and evidence integrity
Usage and cost distinguish complete, partial and unavailable values.
Separate integrity components check references and hashes; OTLP sanitization allows selected fields.
In the project:
Telemetry components have local validation and remain in development.
Integrated activation and full tracing are not proven.
Infrastructure and operational continuity
Separate presentation, API and persistence dependencies.
- The public demo is independent and synthetic.
- Docker Compose manifests define a nonproduction agent environment.
In the project:
Demo availability is public.
Runtime manifests prove infrastructure definition, not integrated operation.
Specifications, contracts and validation
Turn expected behavior into conditions for accepting input, advancing execution and handling failure.
Contracts and negative tests make decisions examinable.
In the project:
Recorded scenarios include invalid input, altered proposals, revoked sources and unavailable integrations.
Briefings separate implementation from validation.
Frameworks and architectural components
Tools appear alongside their role. Integration and telemetry protocols retain their specific scope and implementation stage.
Models and external resources
OpenRouterMCP
OpenRouter connects the service to a language model.
MCP negotiates and lists resources; protocol capabilities are checked before an operation.
Contracts, APIs and applications
FastifyReactNext.js
Fastify organizes assistance routes with Zod input validation.
- React and Next.js support product interfaces.
- Access controls remain on the server.
Persistence and context
PostgreSQLSupabase
PostgreSQL provides lexical memory queries and migrations.
- Supabase and RLS policies appear in the agent persistence structure.
- Real database validation is pending in this slice.
Environments and telemetry
DockerOTLP
Docker Compose defines a nonproduction runtime environment.
- OTLP appears in telemetry sanitization components under development.
- Configuration and local tests do not certify integrated activation.
Project experience
Experience organized by project scope. Responsibilities, outcomes and stage are linked in the case studies above.
Operations platform with AI
Work connecting product experience to AI assistance: module organization, access contracts and an independent demonstration.
The interface exposes user workflows; API scenarios examine controls separately.
Agent and automation platform
Work at the boundary between assisted decisions and effects: approval conditions, authorized sources, execution ownership and connector behavior.
The case explains states, refusal rules and resumption scenarios.
How I work
- 01
Define the problem and expected behavior
Examine documented scenarios (PT) ↗Connect the product need to examinable rules.
The agent runtime defines when proposals advance and when changes require new approval.
- 02
Specify contracts and boundaries
Examine documented scenarios (PT) ↗Separate interpretation, authorization and effects.
Assistance tools use validated inputs and bounded operations rather than unrestricted model-selected queries.
- 03
Verify success, refusal and continuity
Examine documented scenarios (PT) ↗Exercise invalid input, revoked sources, authorization errors and concurrent resumption.
Reports identify simulated dependencies and scenario scope.
- 04
Document delivery and next validation criteria
Examine documented scenarios (PT) ↗Record architecture, decisions and stage.
A demo, local test and manifest prove different aspects; real databases and integrations need their own validation.