Portfolio · evidence reviewed August 2026

Operations-first systems builder

I identify fragile, repetitive, or invisible work inside businesses and teams and turn it into practical systems that people can actually use.

My work connects existing tools, custom workflows, automation, and increasingly AI assistance. AI accelerates my process, but it did not create it. My core skill is understanding how work actually happens and building the missing pieces that make it clearer, more reliable, and easier to manage.

My employment kept me close to real operations — customers, escalations, teams under daily pressure. The systems here are what I built alongside those roles; this portfolio is where the two converge.

ISO/IEC 27001 consulting background. I design automation with authority, data movement, credentials, review points, and failure behavior considered from the start.

Where this fits →

Three proof points

Operations before AI, architecture at scale, then AI-era coordination

Annual billing that took two people six weeks (Ative)

Automated an annual billing workflow around Primavera ERP that had previously required two people approximately six weeks of manual work.

~6 weeks → one run invoice launching Operated · four cycles

The problem: Annual customer billing took two people approximately six weeks. Each year the conditions of approximately 3,800 service contracts had to be updated, and each customer then invoiced one at a time through the ERP's normal interface.
What existed before: The Primavera database had been migrated from an earlier system and contract information sat in custom fields. Primavera could display that information and launch invoices manually, but its own automation could not operate over those legacy fields. The data was inside the ERP; the ERP's functions could not use it.
What I designed and built: A workflow that created the annual invoices directly in the Primavera database. The work was in the reconciliation: matching database keys correctly and generating nothing outside normal invoicing parameters, so every invoice the workflow created was indistinguishable from one launched manually through the application. Primavera accepted them as its own. The invoice-launching stage became a single automated run where it had previously been thousands of manual operations.
My role: Systems Administrator / Systems Engineer, 2012–2017. Analysis of the database structure, legacy contract fields, and invoice parameters; design and implementation of the workflow; execution of the annual run.
Operational boundaries: Constrained to the ERP's normal invoicing parameters. Keys reconciled before anything was created. Results reviewable inside Primavera like any manually launched invoice.
Evidence / scale: Approximately 3,800 contracts per cycle. Four annual cycles, including the period after I left the company — at the beginning of the year they would still call me to execute the run. The process was fully automated by then, but they wanted the person who built it present when it ran.
Status: Operated · four annual cycles
Known limitations: These events predate my habit of dated evidence snapshots. The figures here are recalled from memory in 2026, roughly a decade later, and no contemporaneous measurements were preserved. They are presented as good-faith recollections, marked approximate, rather than verified metrics. Writing directly to a production ERP database is a technique that demands care; the safeguards described are the design discipline applied at the time, not a formal audit.
Technologies: Primavera ERP · Microsoft SQL Server · SSRS · Windows Server · RemoteApp

Operations run from spreadsheets and shared credentials (BabySharks)

Built an interconnected operating environment from processes that had previously depended on spreadsheets, Telegram notes, shared credentials, manual file handling, and individual procedures.

~200 community members Operated · August 2026

The problem: What began in July 2023 as a small collection of experiments grew into an operational environment that outran the way it was being managed. Coordinating accounts, devices, operators, and activity across a growing community had no central record.
What existed before: Administrators shared Google accounts on personal phones and changed game profiles manually. This could overwrite account information, was inaccessible to players without suitable devices, and made offboarding dependent on former members voluntarily deleting account data. Moving accounts between teams meant manually reorganizing emulator folders and sharing further credentials.
What I designed and built: Centralized account records, automated file distribution, purpose-built launchers, role-based access, and automatic removal of account files when they are no longer assigned. Administrators now view account details, assignments, activity, and statistics in one place, and account movements are handled through central records instead of moving files or sharing more credentials. Bshome provides the central entry point, user roles, administration, and access to the tools; shared account and gang records feed the synchronization, launcher, claiming, roster, ranking, and reporting applications.
My role: Identifying operational needs, designing workflows, directing AI-assisted development, integrating the applications, deploying them, and maintaining their continued evolution. The first version of the Sentry monitoring program was created by another developer; when that developer left in January 2025 I took responsibility for evolving the concept and connecting it to the wider ecosystem.
Operational boundaries: AI is used selectively — to interpret screenshots, extract names and operational information, assist with statistics, create communication materials, and accelerate development. People remain responsible for access decisions, account movements, and other sensitive actions.
Evidence / scale August 2026: Approximately 200 community members and more than 325 shared accounts. The platform reaches approximately 75 Android emulator instances: 51 centrally operated (13 Sentry emulators monitoring one gang each, 14 supporting FillMap automation, 24 forming the shared Bot environment) plus six independent operator stations averaging four emulators each. The operational archive holds approximately 230,000 build records and 12,000 supporting images.
Status: Operated · August 2026
Known limitations: The platform has not undergone an independent security audit and has known security limitations. The implemented roles, automated offboarding, and authorization boundaries are practical risk reductions — not proof that the platform is secure or compliant.
Technologies: Android emulation · Remote-Sync · AndroidSyncApp · BSLauncher · OSLink · guided automation · screenshot interpretation · Telegram integration

Project status you cannot check (Project Command Center)

Built a private command center that connects project plans, repository activity, evidence, and work items with bounded agent assistance, while keeping consequential authority with a person.

67 projects tracked Operated · August 2026

The problem: Project information was scattered across repositories, commits, documentation, running services, and agent conversations. That made it difficult to see what was genuinely implemented, what evidence supported each status, and what should happen next without rebuilding context repeatedly.
What I designed and built: A private portfolio and work-coordination system connecting plans and Kanban work with evidence from the systems where implementation actually happens. GitHub webhook events enter through a narrowly exposed, signature-verified endpoint; the rest of the application remains private and provides an owner-controlled view of projects, repositories, evidence, and work items. Incoming repository activity is retained as raw delivery evidence before being interpreted, which makes it possible to distinguish a claim in a status card from the commits, events, or other artifacts supporting it.
My role: Identified the coordination problem, designed the workflow, directed AI-assisted implementation, integrated the components, deployed the system, and refined it through operational use.
Operational boundaries: The system provides bounded project context to a dedicated Hermes coordinator. Hermes is an upstream agent runtime that I configured and extended for this workflow rather than software I authored in full. The coordinator can research, retrieve project context, register projects, and manage defined work items through restricted interfaces. It cannot edit repositories or operate as an unrestricted shell agent. I retain authority over implementation, deployment, credentials, and consequential changes. The user interface is available on the private network; only the authenticated webhook route needs public reachability.
Evidence / scale August 2026: 67 projects and 68 repositories. 6,124 raw deliveries retained, 6,886 derived evidence records, 46 work items managed.
Status: Operated · August 2026
Known limitations: These figures demonstrate an active evidence pipeline, not the quality or completion of every project represented inside it. One scheduled Hermes task had a known provider-model error at the snapshot; I therefore describe the dashboard and ingest path as operated while treating individual agent schedules as separately verifiable components.
Technologies: PostgreSQL · Redis · self-hosted deployment · GitHub webhooks with signature verification · Hermes agent runtime (upstream)

Working with AI, with a human owner

How I run a bounded AI assistant

An AI assistant is useful when it has good context, restricted tools, and a named human owner for every consequential action.

Across my systems the same separations recur: reading is separated from writing, drafting from sending, observation from modification, confident matches from ambiguous ones. The assistant prepares work and surfaces context; a person owns what happens next.

Project Command Center — a Hermes coordinator with bounded project context and restricted interfaces. It can research, retrieve context, and manage defined work items, but cannot edit repositories or act as an unrestricted shell agent.
Unified email review — AI assists classification and drafting; drafting and sending are separate stages; a person controls final content, recipient, and timing.
WhatsApp → CRM reconciliation — the Kairos agent records sourced contact information only on sufficiently clear evidence; ambiguous matches are left for human attention rather than guessed.

This is the operating model I would bring to any AI-assisted role.

Supporting systems

Six operational problems and the systems built around them

Guest operations intake and CRM workflow

Check-in information, email authentication, and guest messages arrive through different systems. One reviewed operational record, with each piece of information keeping its source.

711 messages archived Completed — not deployed Listener operated

The problem: Guest check-in information lived in TalkGuest and had to be reviewed or transferred into the operational CRM manually. Access could also require an email-delivered one-time code, adding another interruption to an already repetitive workflow. Separately, important operational updates arrived in a personal WhatsApp account and required repeated application checks.
What I designed and built: The information path from the source portal into Kairos, an operations workspace built on the open-source Twenty CRM. A Playwright worker signs in through the normal web interface, retrieves check-in information, normalizes it, and records processing state locally. It detects previously processed records before delivery, supporting repeatable runs while reducing the risk that retries create duplicate CRM information. A separate read-only WhatsApp listener subscribes to a deliberately limited set of chats, normalizes accepted events, and forwards them on independent paths to Telegram and to Hermes.
My role: Designed the read-only source integration, directed AI-assisted implementation, connected OTP retrieval through myemail, and developed the destination workflow and Twenty customizations. Twenty is credited as the upstream CRM; my contribution is the workflow design, custom data model, integration layer, and operational behavior built around it.
Operational boundaries: The source application is never modified — the boundary with TalkGuest is read-only. When authentication requires an email code, the worker uses a narrowly scoped myemail read interface to locate the relevant message; it does not receive general authority to manage mail or send responses. The WhatsApp listener does not send from the personal account or modify the source conversation. When the Kairos agent finds sufficiently clear evidence it records the contact with WhatsApp provenance and can set it as the preferred operational contact, without overwriting the fact that another source supplied the original booking. If the reservation match is ambiguous, the workflow leaves it unresolved for human attention rather than guessing.
Evidence / scale August 2026: The privately deployed listener had archived 711 messages from its permitted source. Delivery paths fail independently: a temporary problem with one destination does not erase the event or prevent the other path from being attempted, and retries are tracked to avoid duplicate alerts.
Status: Completed — not deployed · TalkGuest → CRM Operated · WhatsApp listener
Known limitations: The TalkGuest-to-CRM integration was completed and validated but not operationally deployed at the August 2026 review; deployment still depended on production credentials and final destination configuration. Reduced copying, fewer transcription opportunities, and better CRM availability are therefore presented as intended operational value rather than measured production impact.
Technologies: Playwright browser automation · Twenty CRM (upstream) · Kairos workspace · Hermes · Telegram · myemail OTP interface

Institutional memory (KnowledgeForge)

Useful knowledge was becoming trapped in documents, repositories, reports, conversations, and individual agent sessions. A durable memory and retrieval layer for both people and AI-assisted workflows.

~43,600 indexed chunks Operated · core

The problem: Knowledge was accumulating across repositories, documents, reports, conversations, and agent sessions. It was difficult to retrieve consistently or carry into later work without rediscovering the same context or depending on a particular chat history.
What I designed and built: A reusable institutional-memory layer. Documents, reports, code, selected conversations, and curated memory artifacts enter a searchable store with their origin and type preserved, so retrieved material can be interpreted in context. The service supports direct search as well as agent-oriented interfaces, letting later tasks recover decisions, implementation evidence, and reports without copying an entire historical conversation into every new session.
My role: Identified the memory problem, designed ingestion and retrieval workflows, directed AI-assisted implementation, integrated the sources, deployed the core privately, and continued improving its access model.
Operational boundaries: Retrieval provides relevant prior material; it does not turn every ingested statement into truth. People and agents still need to evaluate source, date, and authority. Remote access uses private Tailscale networking, and fixed-station onboarding uses scoped, revocable credentials with installation tooling for Linux and Windows stations.
Evidence / scale August 2026: Approximately 43,600 indexed chunks across documents, code, conversations, and curated memory artifacts.
Status: Operated · core Prototype · Explorer
Known limitations: The volume demonstrates breadth of ingestion, not the correctness, usefulness, or current relevance of every stored chunk. The access controls are concrete but are not proof of formal security: the system has not been independently audited, and the current embedding path uses an external model provider, so it is not an entirely local processing stack. KnowledgeForge Explorer is a working prototype rather than a deployed user-facing service.
Technologies: Vector search · Tailscale private networking · scoped revocable credentials · Linux and Windows station tooling

Monitoring and alerts

Systems should bring relevant changes to the person who needs them rather than depending on someone repeatedly checking every source application.

~58,000 observed records Operated · August 2026

The problem: Keeping track of feed activity required someone to check the source application repeatedly, and relevant changes were easy to miss.
What I designed and built: An operated, headless monitoring service that records observed feed activity and sends Telegram alerts, with a companion explorer for inspecting the accumulated records.
Operational boundaries: The claim is monitoring, retention, and notification — not ownership of the platform, control of it, or reliable unattended publishing.
Evidence / scale August 2026: Nearly 58,000 observed post records in the database at the snapshot.
Status: Operated · monitoring Inactive · posting API
Known limitations: A separate posting API existed but was not listening at the snapshot, so outbound posting is not presented as currently operated. No account or post content is disclosed in this portfolio.
Technologies: Headless monitoring service · Telegram alerting · companion record explorer

Unified email review (myemail)

Important messages were spread across Gmail, Hotmail, and Migadu. One review workspace: sort, draft, review, then send.

5 connected mailboxes Operated · daily use

The problem: Important messages were distributed across Gmail, Hotmail, and Migadu accounts. Repeatedly switching inboxes made it harder to maintain one consistent process for sorting, drafting, reviewing, and responding.
What I designed and built: A unified review workspace rather than another autonomous mail sender. Messages from the connected mailboxes synchronize into one central interface, which can organize them for review and turn selected messages into follow-up tasks. The operating sequence is deliberately simple: sort, draft, review, then send.
My role: Identified the fragmented-inbox problem, designed the workflow, directed AI-assisted development, integrated the providers, deployed the service, and refined it through ongoing personal use.
Operational boundaries: AI assists with classification and draft preparation, but drafting and sending are separate stages, so generated text does not automatically become an external communication. A person retains authority over final content, recipient, timing, and the decision to communicate. The system exposes narrow read interfaces for dependent automations — the TalkGuest worker can retrieve a relevant one-time code without receiving broad mailbox access or send authority. Audit entries record important processing actions.
Evidence / scale August 2026: Five connected mailboxes across three provider families, deployed and operating in daily use, with a unified message and task workflow and hundreds of audit entries.
Status: Operated · with known validation debt
Known limitations: Operation does not mean the current development checkout is defect-free. Verification found 52 passing tests and three failures, together with three TypeScript errors. I therefore do not describe myemail as production-ready, formally audited, or fully reliable. The honest status is an operated personal system with demonstrated value and known validation debt. No formal time study was performed, so the case supports qualitative claims about consolidation, review consistency, auditability, and reusable access boundaries rather than productivity figures.
Technologies: Gmail · Hotmail · Migadu · unified sync layer · AI classification and drafting · audit records · scoped read interfaces

Messaging operations (Telegram)

Governance of a messaging ecosystem: discovering what exists, organizing it, and separating account authorization from credential registry.

283 channels organized Operated · August 2026

The problem: Channels, accounts, and bot credentials had accumulated across multiple personal accounts with no inventory of what existed or which code referenced which credential.
What I designed and built: Personal Telegram is a deployed web application for organizing channels across multiple personal accounts with account-aware synchronization and tagging. TGsecrets is a separately deployed registry that inventories Telegram bot credentials and their code references.
Operational boundaries: TGsecrets inventories credentials and their code references without presenting secret values. Account authorization and bot-registry concerns are kept separate.
Evidence / scale August 2026: Three connected accounts, 283 channels, eight tags, and 74 bots. These counts are aggregate evidence; identities and channel names are excluded.
Status: Operated · August 2026
Technologies: Telegram client integration · account-aware synchronization · tagging · credential registry

Private remote operations (Invidtiv)

A central control surface for selected private-network tools and services over Tailscale, replacing the need to remember individual addresses and runtimes.

Operated · August 2026

The problem: Private-network tools and services each required remembering individual addresses and runtimes.
What I designed and built: An operated command-center dashboard linking private tailnet tools and selected control functions, providing a central entrance to services that would otherwise be reached individually.
Evidence / scale: Operated at the August 2026 snapshot. Private network and host details are omitted from this portfolio.
Status: Operated · Invidtiv Inactive · SSH Bridge
Known limitations: The related SSH Bridge — a FastAPI service, web dashboard, and OpenSSH server for managing tunnel access on the private network — was deployed previously and is currently inactive. Deployment artifacts and persistent state remain, but no containers were running at the snapshot. The combined status is therefore component-specific.
Technologies: Tailscale private networking · dashboard control plane · FastAPI · OpenSSH

Additional working tools support the systems above: a report-viewing utility (PageServer, a Flask-based library for viewing agent- and project-generated HTML, Markdown, and image artifacts through a consistent browser interface), private text-to-speech interfaces (web operated; Android a buildable prototype), and a previously deployed SSH tunnel manager (inactive at the August 2026 snapshot). Details available on request.

Additional projects

Prototypes, prospective-client work, and experiments

Two-way spoken interaction over a private network (Hermes Android Voice)

A Hermes gateway plugin and Android companion enabling two-way spoken interaction over Tailscale, without using the telephone network.

Prototype · August 2026

What it does: Connects a Hermes gateway plugin to an Android companion for spoken interaction over the private network. Hermes is credited as the upstream agent runtime.
Evidence: 85 automated tests passed, with active private-network voice and control listeners at the snapshot.
Status: Prototype · August 2026
Known limitations: It remains a working prototype because operation used a development launcher, and no completed phone pilot or soak test was evidenced.

Operating systems for two independent service businesses

Two anonymized prospective-client projects translating owner-operated business requirements into coherent customer and administrator workflows.

Completed — not deployed · August 2026

The problem: Two independent service professionals needed more coherent digital operations. Customer discovery, bookings, follow-up, content creation, publishing, and administration were split across manual processes and disconnected tools, with the same person responsible for delivering the service, attracting customers, handling bookings, and running daily administration.
What I designed and built: The Client Operations Platform combined customer discovery, booking, client records, scheduling, reminders, communications, and privacy workflows — including consent handling, data export, deletion workflows, access controls, and audit records around sensitive operations. The Content and Booking Platform combined a public conversion site with an administrator workspace for retreats, inquiries, campaigns, content, scheduling, media, and analytics.
My role: Translated each prospect's needs into an operating model, designed customer and administrator workflows, directed AI-assisted implementation, integrated the major components, reviewed and hardened the resulting systems, and documented their deployment requirements and limitations. Clients contributed discovery input and domain needs; open-source frameworks and external services supplied foundations.
Operational boundaries: AI could assist with content drafting, summarization, image generation, and other preparatory work, but content passed through approval before scheduling or publication. Business owners retained authority over bookings, generated content, external-service configuration, and anything sent or published.
Status: Completed — not deployed
Known limitations: Both systems reached completed prototype or MVP stage but were not commercially deployed, because the engagements did not proceed for non-technical reasons. Telegram was the only implemented live publishing path documented in the archive; LinkedIn, Instagram, and Facebook remained manual or mocked pending real integrations and external approvals. Neither platform received a formal security audit or completed real-world production validation. Their safeguards are implementation evidence, not a claim of compliance or operational reliability.

Testing the limits of agent autonomy

Clawteam Agent Squad and the QuietSystems/Paperclip Incubator explored agent-run development organizations with explicit work-control planes and Kanban sources of truth.

Experiment · August 2026

What they produced: Meaningful orchestration designs, role models, and operating documentation.
What they exposed: Unresolved runtime and governance gaps, including enforcement, retry, QA, and synchronization concerns.
Status: Experiment · learning artifact
Known limitations: Presented as partial experiments and learning artifacts, not autonomous production organizations. Their value lies in tested boundaries and lessons, not claims of unattended delivery. Included here as evidence that I test the limits of agent autonomy before recommending it.

Security and governance

Authority, data movement, and failure behavior, considered from the start

I think explicitly about authority, data movement, credentials, review points, and failure behavior when designing automation.

Security is treated as concrete boundaries rather than a label. The recurring practical controls across the newer projects:

Role-based access
Read-only integrations
Scoped credentials
Private Tailscale networking
Signature verification
Provenance
Audit records
Automatic offboarding
Restricted agent interfaces
Human approval for consequential actions
Fail-closed matching

The portfolio also records limitations directly: inactive components, external model use, missing deployment validation, failed checks, mocked publishers, and experiments that did not reach production.

Several hundred automated tests pass across the portfolio's operated systems at the August 2026 snapshot. Per-project counts appear in each case's Level 3 evidence, alongside recorded failures. Several systems have not undergone independent security audits; that limitation stays visible in the status fields where material.

Career

Keeping real businesses running since 1997

2023 — present Independent systems builder Personal portfolio. Carried out alongside employment until April 2026, and full-time since.
Feb 2024 — Apr 2026 Call Center Team Leader Teleperformance, Lisboa. Led a team of 28 customer service agents: daily operations coordination, performance and service-quality monitoring, coaching and feedback, and support in resolving escalated customer cases.
Feb 2023 — Feb 2024 Call Center Agent Teleperformance, Lisboa.
Nov 2017 — Sep 2022 Systems Engineer and Administrator Private venture. Planned, engineered, and ran a 50-GPU mining operation: physical build-out, Linux administration, MySQL, and API-based data collection for monitoring.
Dec 2017 — Jul 2018 Information Security Consultant (ISO/IEC 27001:2013) Global Score Lda., management consultancy.
Mar 2012 — May 2017 Systems Administrator / Systems Engineer Ative Lda., industrial health and safety, 34 people. Windows Server, SQL Server, SSRS, Primavera ERP, networking, helpdesk.
Jun 2007 — present Systems Administrator (ongoing support) Cópia Igual Lda., printing shop.
Jan 2006 — present IT Freelancer Systems and server upgrades, networking, general IT.
Jan 1997 — Sep 2011 Customer Service and Print Production CIAU Lda., printing shop. AutoCAD and Adobe professional tools.

My employment history and my systems work ran in parallel. The roles paid the bills and kept me close to real operations — customers, escalations, team performance, daily service pressure. The systems in this portfolio are what I built alongside and after those roles, and they are the demonstration that the capability outgrew the jobs. Since April 2026 I do this work full time, as a freelancer under Quiet Systems and, for the right team, in a role where the two converge.

Internal tools, data, and processes at Teleperformance are not described here or in the portfolio, in line with confidentiality obligations.

Training — ISO/IEC 27001:2013 Information Security (IPAC, 2017) · Microsoft MCSE/MCSA and Cisco CCNA (Galileu, 2006) · Audiovisual Technician (2001). Languages — Portuguese native · English C2 reading and listening, C1 writing · French C2 reading and listening, B2 writing. CEFR self-assessment.

Where this fits

I learn workflows quickly and build around what a business already relies on

I learn workflows quickly, find where the real operational problems are, and build careful, useful improvements around the tools a business already relies on. If you run a business and recognise this kind of work, Quiet Systems is how I take it on: a scoped audit first, then the system. If you are hiring for a team where this converges — operations, internal tools, and an AI toolkit that needs a human owner — that is the skill that transfers directly.

Get in touch → Quiet Systems →

Portefólio · evidência revista em agosto de 2026

Construtor de sistemas orientado às operações

Identifico trabalho frágil, repetitivo ou invisível dentro de negócios e equipas e transformo-o em sistemas práticos que as pessoas conseguem mesmo usar.

O meu trabalho liga ferramentas existentes, fluxos de trabalho à medida, automação e, cada vez mais, assistência de IA. A IA acelera o meu processo, mas não o criou. A minha competência central é perceber como o trabalho acontece na prática e construir as peças em falta que o tornam mais claro, mais fiável e mais fácil de gerir.

O meu percurso profissional manteve-me próximo das operações reais — clientes, escalamentos, equipas sob pressão diária. Os sistemas aqui apresentados são o que construí em paralelo com essas funções; este portefólio é onde os dois convergem.

Formação em consultoria ISO/IEC 27001. Desenho automação considerando desde o início a autoridade, o movimento de dados, as credenciais, os pontos de revisão e o comportamento em caso de falha.

Onde isto se enquadra →

Três provas concretas

Operações antes da IA, arquitetura à escala, depois coordenação na era da IA

Faturação anual que ocupava duas pessoas durante seis semanas (Ative)

Automatizei um processo de faturação anual em torno do ERP Primavera que antes exigia cerca de seis semanas de trabalho manual de duas pessoas.

~6 semanas → uma execução lançamento de faturas Em operação · quatro ciclos

O problema: A faturação anual de clientes ocupava duas pessoas durante cerca de seis semanas. Todos os anos era necessário atualizar as condições de aproximadamente 3.800 contratos de serviço e faturar cada cliente individualmente através da interface normal do ERP.
O que existia antes: A base de dados Primavera tinha sido migrada de um sistema anterior e a informação contratual ficara em campos personalizados. O Primavera conseguia mostrar essa informação e lançar faturas manualmente, mas a sua própria automação não operava sobre esses campos legados. Os dados estavam dentro do ERP; as funções do ERP não os conseguiam usar.
O que concebi e construí: Um processo que criava as faturas anuais diretamente na base de dados do Primavera. O trabalho estava na reconciliação: fazer corresponder corretamente as chaves da base de dados e não gerar nada fora dos parâmetros normais de faturação, para que cada fatura criada fosse indistinguível de uma lançada manualmente através da aplicação. O Primavera aceitava-as como suas. A fase de lançamento de faturas passou a ser uma única execução automática, onde antes eram milhares de operações manuais.
O meu papel: Administrador de Sistemas / Engenheiro de Sistemas, 2012–2017. Análise da estrutura da base de dados, dos campos contratuais legados e dos parâmetros de fatura; conceção e implementação do processo; execução da corrida anual.
Fronteiras operacionais: Limitado aos parâmetros normais de faturação do ERP. Chaves reconciliadas antes de qualquer criação. Resultados revistos dentro do Primavera como qualquer fatura lançada manualmente.
Evidência / escala: Aproximadamente 3.800 contratos por ciclo. Quatro ciclos anuais, incluindo o período após a minha saída da empresa — no início do ano continuavam a chamar-me para executar a corrida. O processo já estava totalmente automatizado, mas queriam a pessoa que o construiu presente quando corria.
Estado: Em operação · quatro ciclos anuais
Limitações conhecidas: Estes acontecimentos são anteriores ao meu hábito de registar evidência datada. Os números aqui apresentados são recordados de memória em 2026, cerca de uma década depois, e não foram preservadas medições da época. São apresentados como recordações de boa-fé, assinaladas como aproximadas, e não como métricas verificadas. Escrever diretamente numa base de dados de ERP em produção é uma técnica que exige cuidado; as salvaguardas descritas são a disciplina de conceção aplicada na altura, não uma auditoria formal.
Tecnologias: Primavera ERP · Microsoft SQL Server · SSRS · Windows Server · RemoteApp

Operações geridas a partir de folhas de cálculo e credenciais partilhadas (BabySharks)

Construí um ambiente operacional interligado a partir de processos que antes dependiam de folhas de cálculo, notas de Telegram, credenciais partilhadas, manipulação manual de ficheiros e procedimentos individuais.

~200 membros da comunidade Em operação · agosto de 2026

O problema: O que começou em julho de 2023 como um pequeno conjunto de experiências cresceu para um ambiente operacional que ultrapassou a forma como estava a ser gerido. Coordenar contas, dispositivos, operadores e atividade numa comunidade em crescimento não tinha registo central.
O que existia antes: Os administradores partilhavam contas Google em telemóveis pessoais e alteravam perfis de jogo manualmente. Isto podia sobrescrever informação de conta, era inacessível a jogadores sem dispositivos adequados e tornava a saída de membros dependente da eliminação voluntária dos dados por ex-membros. Mover contas entre equipas implicava reorganizar manualmente pastas de emuladores e partilhar mais credenciais.
O que concebi e construí: Registos centralizados de contas, distribuição automática de ficheiros, lançadores dedicados, acesso baseado em funções e remoção automática dos ficheiros de conta quando deixam de estar atribuídos. Os administradores veem agora detalhes de conta, atribuições, atividade e estatísticas num só lugar, e os movimentos de conta são tratados através de registos centrais em vez de mover ficheiros ou partilhar mais credenciais. O Bshome fornece o ponto de entrada central, as funções de utilizador, a administração e o acesso às ferramentas; os registos partilhados de contas e gangs alimentam as aplicações de sincronização, lançamento, atribuição, roster, ranking e relatórios.
O meu papel: Identificação de necessidades operacionais, desenho de fluxos de trabalho, direção de desenvolvimento assistido por IA, integração das aplicações, implementação e manutenção da sua evolução contínua. A primeira versão do programa de monitorização Sentry foi criada por outro programador; quando esse programador saiu em janeiro de 2025, assumi a responsabilidade de evoluir o conceito e de o ligar ao ecossistema mais amplo.
Fronteiras operacionais: A IA é usada de forma seletiva — para interpretar capturas de ecrã, extrair nomes e informação operacional, apoiar estatísticas, criar materiais de comunicação e acelerar o desenvolvimento. As pessoas continuam responsáveis por decisões de acesso, movimentos de conta e outras ações sensíveis.
Evidência / escala agosto de 2026: Aproximadamente 200 membros da comunidade e mais de 325 contas partilhadas. A plataforma alcança cerca de 75 instâncias de emulador Android: 51 operadas centralmente (13 emuladores Sentry a monitorizar um gang cada, 14 a apoiar automação FillMap, 24 a formar o ambiente Bot partilhado) mais seis estações de operador independentes com uma média de quatro emuladores cada. O arquivo operacional contém aproximadamente 230.000 registos de construção e 12.000 imagens de apoio.
Estado: Em operação · agosto de 2026
Limitações conhecidas: A plataforma não foi sujeita a auditoria de segurança independente e tem limitações de segurança conhecidas. As funções implementadas, a saída automática de membros e as fronteiras de autorização são reduções práticas de risco — não prova de que a plataforma seja segura ou esteja em conformidade.
Tecnologias: Emulação Android · Remote-Sync · AndroidSyncApp · BSLauncher · OSLink · automação guiada · interpretação de capturas de ecrã · integração com Telegram

Estado de projeto que não se consegue verificar (Project Command Center)

Construí um centro de comando privado que liga planos de projeto, atividade de repositórios, evidência e itens de trabalho com assistência de agente delimitada, mantendo numa pessoa a autoridade sobre ações consequentes.

67 projetos acompanhados Em operação · agosto de 2026

O problema: A informação de projeto estava dispersa por repositórios, commits, documentação, serviços em execução e conversas com agentes. Isso tornava difícil ver o que estava genuinamente implementado, que evidência sustentava cada estado e o que devia acontecer a seguir sem reconstruir contexto repetidamente.
O que concebi e construí: Um sistema privado de portefólio e coordenação de trabalho que liga planos e trabalho Kanban à evidência dos sistemas onde a implementação realmente acontece. Os eventos de webhook do GitHub entram por um ponto de acesso restrito e com assinatura verificada; o resto da aplicação permanece privado e oferece uma vista controlada pelo proprietário sobre projetos, repositórios, evidência e itens de trabalho. A atividade recebida dos repositórios é retida como evidência de entrega em bruto antes de ser interpretada, o que permite distinguir uma afirmação num cartão de estado dos commits, eventos ou outros artefactos que a sustentam.
O meu papel: Identifiquei o problema de coordenação, desenhei o fluxo de trabalho, dirigi a implementação assistida por IA, integrei os componentes, implementei o sistema e refinei-o através do uso operacional.
Fronteiras operacionais: O sistema fornece contexto de projeto delimitado a um coordenador Hermes dedicado. O Hermes é um runtime de agente a montante que configurei e estendi para este fluxo de trabalho, e não software que eu tenha escrito na totalidade. O coordenador pode pesquisar, obter contexto de projeto, registar projetos e gerir itens de trabalho definidos através de interfaces restritas. Não pode editar repositórios nem operar como agente de shell sem restrições. Mantenho autoridade sobre implementação, colocação em produção, credenciais e alterações consequentes. A interface de utilizador está disponível na rede privada; apenas a rota de webhook autenticada precisa de ser alcançável publicamente.
Evidência / escala agosto de 2026: 67 projetos e 68 repositórios. 6.124 entregas em bruto retidas, 6.886 registos de evidência derivados, 46 itens de trabalho geridos.
Estado: Em operação · agosto de 2026
Limitações conhecidas: Estes números demonstram um pipeline de evidência ativo, não a qualidade ou a conclusão de cada projeto nele representado. Uma tarefa Hermes agendada tinha um erro conhecido de modelo do fornecedor no momento do levantamento; descrevo por isso o painel e o caminho de ingestão como em operação, tratando os agendamentos individuais de agente como componentes verificáveis separadamente.
Tecnologias: PostgreSQL · Redis · alojamento próprio · webhooks GitHub com verificação de assinatura · runtime de agente Hermes (a montante)

Trabalhar com IA, com um dono humano

Como opero um assistente de IA delimitado

Um assistente de IA é útil quando tem bom contexto, ferramentas restritas e um dono humano identificado para cada ação consequente.

Nos meus sistemas repetem-se as mesmas separações: a leitura está separada da escrita, a redação do envio, a observação da modificação, as correspondências seguras das ambíguas. O assistente prepara trabalho e traz contexto; uma pessoa é dona do que acontece a seguir.

Project Command Center — um coordenador Hermes com contexto de projeto delimitado e interfaces restritas. Pode pesquisar, obter contexto e gerir itens de trabalho definidos, mas não pode editar repositórios nem agir como agente de shell sem restrições.
Revisão unificada de correio — a IA apoia a classificação e a redação; redigir e enviar são fases separadas; uma pessoa controla o conteúdo final, o destinatário e o momento.
Reconciliação WhatsApp → CRM — o agente Kairos regista informação de contacto com a devida proveniência apenas perante evidência suficientemente clara; correspondências ambíguas ficam para atenção humana em vez de serem adivinhadas.

Este é o modelo de operação que levaria para qualquer função assistida por IA.

Sistemas de apoio

Seis problemas operacionais e os sistemas construídos à sua volta

Receção de operações de hóspedes e fluxo para CRM

Informação de check-in, autenticação por email e mensagens de hóspedes chegam por sistemas diferentes. Um registo operacional revisto, com cada informação a manter a sua origem.

711 mensagens arquivadas Concluído — não em produção Escuta em operação

O problema: A informação de check-in dos hóspedes vivia no TalkGuest e tinha de ser revista ou transferida manualmente para o CRM operacional. O acesso podia ainda exigir um código de uso único enviado por email, acrescentando outra interrupção a um fluxo já repetitivo. Em separado, atualizações operacionais importantes chegavam a uma conta pessoal de WhatsApp e exigiam verificações repetidas da aplicação.
O que concebi e construí: O caminho da informação desde o portal de origem até ao Kairos, um espaço de trabalho operacional construído sobre o Twenty CRM de código aberto. Um worker Playwright autentica-se pela interface web normal, obtém a informação de check-in, normaliza-a e regista localmente o estado de processamento. Deteta registos já processados antes da entrega, o que permite execuções repetíveis reduzindo o risco de que novas tentativas criem informação duplicada no CRM. Um serviço de escuta de WhatsApp, apenas de leitura, subscreve um conjunto deliberadamente limitado de conversas, normaliza os eventos aceites e encaminha-os por vias independentes para o Telegram e para o Hermes.
O meu papel: Desenhei a integração de origem apenas de leitura, dirigi a implementação assistida por IA, liguei a obtenção do código de uso único através do myemail e desenvolvi o fluxo de destino e as personalizações do Twenty. O Twenty é creditado como o CRM a montante; o meu contributo é o desenho do fluxo, o modelo de dados personalizado, a camada de integração e o comportamento operacional construído à sua volta.
Fronteiras operacionais: A aplicação de origem nunca é modificada — a fronteira com o TalkGuest é apenas de leitura. Quando a autenticação exige um código por email, o worker usa uma interface de leitura do myemail com âmbito restrito para localizar a mensagem relevante; não recebe autoridade geral para gerir correio ou enviar respostas. O serviço de escuta de WhatsApp não envia a partir da conta pessoal nem modifica a conversa de origem. Quando o agente Kairos encontra evidência suficientemente clara, regista o contacto com proveniência WhatsApp e pode defini-lo como contacto operacional preferido, sem sobrescrever o facto de outra fonte ter fornecido a reserva original. Se a correspondência com a reserva for ambígua, o fluxo deixa-a por resolver para atenção humana em vez de adivinhar.
Evidência / escala agosto de 2026: O serviço de escuta, implementado de forma privada, tinha arquivado 711 mensagens da sua origem autorizada. As vias de entrega falham de forma independente: um problema temporário num destino não apaga o evento nem impede que a outra via seja tentada, e as novas tentativas são registadas para evitar alertas duplicados.
Estado: Concluído — não em produção · TalkGuest → CRM Em operação · escuta WhatsApp
Limitações conhecidas: A integração TalkGuest–CRM estava concluída e validada, mas não em produção à data da revisão de agosto de 2026; a entrada em produção dependia ainda de credenciais de produção e da configuração final do destino. Menos cópia manual, menos oportunidades de erro de transcrição e melhor disponibilidade no CRM são por isso apresentados como valor operacional pretendido, e não como impacto medido em produção.
Tecnologias: Automação de navegador Playwright · Twenty CRM (a montante) · espaço de trabalho Kairos · Hermes · Telegram · interface de códigos do myemail

Memória institucional (KnowledgeForge)

Conhecimento útil estava a ficar preso em documentos, repositórios, relatórios, conversas e sessões individuais de agentes. Uma camada durável de memória e recuperação para pessoas e para fluxos assistidos por IA.

~43.600 blocos indexados Em operação · núcleo

O problema: O conhecimento acumulava-se em repositórios, documentos, relatórios, conversas e sessões de agentes. Era difícil de recuperar de forma consistente ou de transportar para trabalho posterior sem redescobrir o mesmo contexto ou depender de um histórico de conversa específico.
O que concebi e construí: Uma camada reutilizável de memória institucional. Documentos, relatórios, código, conversas selecionadas e artefactos de memória curados entram num repositório pesquisável, com a origem e o tipo preservados, para que o material recuperado possa ser interpretado em contexto. O serviço suporta pesquisa direta e também interfaces orientadas a agentes, permitindo que tarefas posteriores recuperem decisões, evidência de implementação e relatórios sem copiar uma conversa histórica inteira para cada nova sessão.
O meu papel: Identifiquei o problema de memória, desenhei os fluxos de ingestão e recuperação, dirigi a implementação assistida por IA, integrei as fontes, implementei o núcleo de forma privada e continuei a melhorar o seu modelo de acesso.
Fronteiras operacionais: A recuperação fornece material anterior relevante; não transforma cada afirmação ingerida em verdade. Pessoas e agentes continuam a ter de avaliar origem, data e autoridade. O acesso remoto usa rede privada Tailscale, e a adesão de estações fixas usa credenciais de âmbito restrito e revogáveis, com ferramentas de instalação para estações Linux e Windows.
Evidência / escala agosto de 2026: Aproximadamente 43.600 blocos indexados em documentos, código, conversas e artefactos de memória curados.
Estado: Em operação · núcleo Protótipo · Explorer
Limitações conhecidas: O volume demonstra amplitude de ingestão, não a correção, utilidade ou relevância atual de cada bloco armazenado. Os controlos de acesso são concretos, mas não constituem prova de segurança formal: o sistema não foi auditado de forma independente e o caminho de embeddings atual usa um fornecedor de modelo externo, pelo que não é uma cadeia de processamento inteiramente local. O KnowledgeForge Explorer é um protótipo funcional e não um serviço implementado para utilizadores finais.
Tecnologias: Pesquisa vetorial · rede privada Tailscale · credenciais de âmbito restrito e revogáveis · ferramentas para estações Linux e Windows

Monitorização e alertas

Os sistemas devem levar as alterações relevantes a quem precisa delas, em vez de depender de alguém que verifica repetidamente cada aplicação de origem.

~58.000 registos observados Em operação · agosto de 2026

O problema: Acompanhar a atividade de um feed exigia que alguém verificasse repetidamente a aplicação de origem, e as alterações relevantes passavam facilmente despercebidas.
O que concebi e construí: Um serviço de monitorização sem interface gráfica, em operação, que regista a atividade observada no feed e envia alertas por Telegram, com um explorador companheiro para inspecionar os registos acumulados.
Fronteiras operacionais: A afirmação é monitorização, retenção e notificação — não propriedade da plataforma, controlo sobre ela, nem publicação automática fiável sem supervisão.
Evidência / escala agosto de 2026: Quase 58.000 registos de publicações observadas na base de dados à data do levantamento.
Estado: Em operação · monitorização Inativo · API de publicação
Limitações conhecidas: Existia uma API de publicação separada, mas não estava à escuta no momento do levantamento, pelo que a publicação para o exterior não é apresentada como estando em operação. Não é divulgado qualquer conteúdo de conta ou de publicação neste portefólio.
Tecnologias: Serviço de monitorização headless · alertas por Telegram · explorador de registos

Revisão unificada de correio (myemail)

As mensagens importantes estavam espalhadas por Gmail, Hotmail e Migadu. Um só espaço de revisão: separar, redigir, rever e depois enviar.

5 caixas de correio ligadas Em operação · uso diário

O problema: As mensagens importantes estavam distribuídas por contas Gmail, Hotmail e Migadu. Alternar repetidamente entre caixas de entrada dificultava manter um processo consistente para separar, redigir, rever e responder.
O que concebi e construí: Um espaço unificado de revisão, e não mais um remetente automático de correio. As mensagens das caixas ligadas sincronizam-se numa interface central, que as pode organizar para revisão e transformar mensagens selecionadas em tarefas de seguimento. A sequência de operação é deliberadamente simples: separar, redigir, rever e depois enviar.
O meu papel: Identifiquei o problema da fragmentação das caixas de entrada, desenhei o fluxo, dirigi o desenvolvimento assistido por IA, integrei os fornecedores, implementei o serviço e refinei-o através do uso pessoal contínuo.
Fronteiras operacionais: A IA apoia a classificação e a preparação de rascunhos, mas redigir e enviar são fases separadas, pelo que o texto gerado não se torna automaticamente uma comunicação externa. Uma pessoa mantém a autoridade sobre o conteúdo final, o destinatário, o momento e a decisão de comunicar. O sistema expõe interfaces de leitura restritas a automações dependentes — o worker do TalkGuest pode obter um código de uso único relevante sem receber acesso alargado à caixa de correio nem autoridade de envio. Os registos de auditoria documentam ações de processamento importantes.
Evidência / escala agosto de 2026: Cinco caixas de correio ligadas de três famílias de fornecedores, implementado e a operar em uso diário, com um fluxo unificado de mensagens e tarefas e centenas de registos de auditoria.
Estado: Em operação · com dívida de validação conhecida
Limitações conhecidas: Estar em operação não significa que a versão de desenvolvimento atual esteja livre de defeitos. A verificação encontrou 52 testes a passar e três a falhar, juntamente com três erros de TypeScript. Não descrevo por isso o myemail como pronto para produção, formalmente auditado ou totalmente fiável. O estado honesto é o de um sistema pessoal em operação, com valor demonstrado e dívida de validação conhecida. Não foi feito qualquer estudo formal de tempo, pelo que o caso sustenta afirmações qualitativas sobre consolidação, consistência de revisão, auditabilidade e fronteiras de acesso reutilizáveis, e não números de produtividade.
Tecnologias: Gmail · Hotmail · Migadu · camada de sincronização unificada · classificação e redação com IA · registos de auditoria · interfaces de leitura restritas

Operações de mensagens (Telegram)

Governação de um ecossistema de mensagens: descobrir o que existe, organizá-lo e separar a autorização de contas do registo de credenciais.

283 canais organizados Em operação · agosto de 2026

O problema: Canais, contas e credenciais de bots tinham-se acumulado em várias contas pessoais, sem inventário do que existia nem de que código referenciava que credencial.
O que concebi e construí: O Personal Telegram é uma aplicação web implementada para organizar canais em várias contas pessoais, com sincronização e etiquetagem sensíveis à conta. O TGsecrets é um registo implementado em separado que inventaria credenciais de bots do Telegram e as suas referências em código.
Fronteiras operacionais: O TGsecrets inventaria credenciais e as suas referências em código sem apresentar valores secretos. A autorização de contas e o registo de bots são mantidos separados.
Evidência / escala agosto de 2026: Três contas ligadas, 283 canais, oito etiquetas e 74 bots. Estas contagens são evidência agregada; identidades e nomes de canais são excluídos.
Estado: Em operação · agosto de 2026
Tecnologias: Integração com cliente Telegram · sincronização sensível à conta · etiquetagem · registo de credenciais

Operações remotas privadas (Invidtiv)

Uma superfície central de controlo para ferramentas e serviços selecionados da rede privada sobre Tailscale, dispensando a necessidade de memorizar endereços e runtimes individuais.

Em operação · agosto de 2026

O problema: Cada ferramenta e serviço da rede privada exigia memorizar endereços e runtimes individuais.
O que concebi e construí: Um painel de centro de comando em operação que liga ferramentas da tailnet privada e funções de controlo selecionadas, servindo de entrada central para serviços que de outro modo seriam alcançados individualmente.
Evidência / escala: Em operação à data do levantamento de agosto de 2026. Detalhes da rede privada e dos anfitriões são omitidos deste portefólio.
Estado: Em operação · Invidtiv Inativo · SSH Bridge
Limitações conhecidas: O SSH Bridge associado — um serviço FastAPI, painel web e servidor OpenSSH para gerir acesso por túnel na rede privada — esteve implementado anteriormente e encontra-se atualmente inativo. Os artefactos de instalação e o estado persistente permanecem, mas não havia contentores em execução no momento do levantamento. O estado combinado é, por isso, específico de cada componente.
Tecnologias: Rede privada Tailscale · painel de controlo · FastAPI · OpenSSH

Outras ferramentas de trabalho apoiam os sistemas acima: um utilitário de visualização de relatórios (PageServer, uma biblioteca em Flask para ver artefactos HTML, Markdown e imagens gerados por agentes e projetos através de uma interface de navegador consistente), interfaces privadas de conversão de texto em fala (a versão web em operação; a versão Android um protótipo compilável) e um gestor de túneis SSH anteriormente implementado (inativo à data do levantamento de agosto de 2026). Mais detalhes a pedido.

Projetos adicionais

Protótipos, trabalho para clientes potenciais e experiências

Interação falada bidirecional sobre rede privada (Hermes Android Voice)

Um plugin de gateway Hermes e uma aplicação companheira Android que permitem interação falada nos dois sentidos sobre Tailscale, sem usar a rede telefónica.

Protótipo · agosto de 2026

O que faz: Liga um plugin de gateway Hermes a uma aplicação companheira Android para interação falada sobre a rede privada. O Hermes é creditado como o runtime de agente a montante.
Evidência: 85 testes automáticos passaram, com serviços de escuta de voz e controlo ativos na rede privada à data do levantamento.
Estado: Protótipo · agosto de 2026
Limitações conhecidas: Continua a ser um protótipo funcional porque a operação usava um lançador de desenvolvimento e não há evidência de um piloto concluído em telemóvel nem de um teste de resistência.

Sistemas operacionais para dois negócios de serviços independentes

Dois projetos anonimizados para clientes potenciais, traduzindo requisitos de negócios geridos pelo próprio dono em fluxos coerentes para clientes e administradores.

Concluído — não em produção · agosto de 2026

O problema: Dois profissionais de serviços independentes precisavam de operações digitais mais coerentes. A captação de clientes, as marcações, o seguimento, a criação de conteúdos, a publicação e a administração estavam repartidos por processos manuais e ferramentas desligadas, com a mesma pessoa responsável por prestar o serviço, atrair clientes, gerir marcações e tratar da administração diária.
O que concebi e construí: A Client Operations Platform reunia captação de clientes, marcações, registos de cliente, agendamento, lembretes, comunicações e fluxos de privacidade — incluindo gestão de consentimento, exportação de dados, fluxos de eliminação, controlos de acesso e registos de auditoria em operações sensíveis. A Content and Booking Platform reunia um site público de conversão com um espaço de administração para retiros, pedidos de informação, campanhas, conteúdos, agendamento, media e analítica.
O meu papel: Traduzi as necessidades de cada cliente potencial num modelo operacional, desenhei os fluxos de cliente e de administrador, dirigi a implementação assistida por IA, integrei os componentes principais, revi e reforcei os sistemas resultantes e documentei os seus requisitos de instalação e limitações. Os clientes contribuíram com levantamento de necessidades e conhecimento do domínio; frameworks de código aberto e serviços externos forneceram as bases.
Fronteiras operacionais: A IA podia apoiar a redação de conteúdos, a sumarização, a geração de imagens e outro trabalho preparatório, mas o conteúdo passava por aprovação antes de ser agendado ou publicado. Os donos do negócio mantinham autoridade sobre marcações, conteúdo gerado, configuração de serviços externos e tudo o que fosse enviado ou publicado.
Estado: Concluído — não em produção
Limitações conhecidas: Ambos os sistemas chegaram a protótipo concluído ou MVP, mas não entraram em produção comercial porque os projetos não avançaram por razões não técnicas. O Telegram foi a única via de publicação em direto efetivamente implementada e documentada no arquivo; LinkedIn, Instagram e Facebook permaneceram manuais ou simulados, à espera de integrações reais e aprovações externas. Nenhuma das plataformas recebeu auditoria formal de segurança nem completou validação real em produção. As suas salvaguardas são evidência de implementação, não uma afirmação de conformidade ou de fiabilidade operacional.

Testar os limites da autonomia de agentes

O Clawteam Agent Squad e o QuietSystems/Paperclip Incubator exploraram organizações de desenvolvimento operadas por agentes, com planos de controlo de trabalho explícitos e Kanban como fonte de verdade.

Experimental · agosto de 2026

O que produziram: Desenhos de orquestração relevantes, modelos de papéis e documentação de operação.
O que expuseram: Lacunas por resolver de runtime e de governação, incluindo aplicação de regras, novas tentativas, controlo de qualidade e sincronização.
Estado: Experimental · artefacto de aprendizagem
Limitações conhecidas: Apresentados como experiências parciais e artefactos de aprendizagem, não como organizações autónomas em produção. O seu valor está nas fronteiras testadas e nas lições retiradas, não em afirmações de entrega sem supervisão. Incluídos aqui como evidência de que testo os limites da autonomia de agentes antes de a recomendar.

Segurança e governação

Autoridade, movimento de dados e comportamento em falha, considerados desde o início

Penso explicitamente sobre autoridade, movimento de dados, credenciais, pontos de revisão e comportamento em caso de falha quando desenho automação.

A segurança é tratada como fronteiras concretas e não como um rótulo. Os controlos práticos recorrentes nos projetos mais recentes:

Acesso baseado em funções
Integrações apenas de leitura
Credenciais de âmbito restrito
Rede privada Tailscale
Verificação de assinatura
Proveniência
Registos de auditoria
Saída automática de acessos
Interfaces de agente restritas
Aprovação humana para ações consequentes
Correspondência fail-closed

O portefólio também regista as limitações de forma direta: componentes inativos, uso de modelos externos, validação de instalação em falta, verificações falhadas, publicadores simulados e experiências que não chegaram a produção.

Várias centenas de testes automáticos passam nos sistemas em operação do portefólio à data do levantamento de agosto de 2026. As contagens por projeto aparecem na evidência de Nível 3 de cada caso, juntamente com as falhas registadas. Vários sistemas não foram sujeitos a auditorias de segurança independentes; essa limitação permanece visível nos campos de estado sempre que é material.

Percurso

A manter negócios reais a funcionar desde 1997

2023 — presente Construtor de sistemas independente Portefólio pessoal. Realizado em paralelo com o emprego até abril de 2026 e a tempo inteiro desde então.
Fev 2024 — Abr 2026 Team Leader de Call Center Teleperformance, Lisboa. Liderei uma equipa de 28 agentes de apoio ao cliente: coordenação das operações diárias, monitorização de desempenho e qualidade de serviço, acompanhamento e feedback, e apoio na resolução de casos escalados.
Fev 2023 — Fev 2024 Agente de Call Center Teleperformance, Lisboa.
Nov 2017 — Set 2022 Engenheiro e Administrador de Sistemas Projeto privado. Planeei, montei e operei uma instalação de mineração com 50 GPU: construção física, administração Linux, MySQL e recolha de dados por API para monitorização.
Dez 2017 — Jul 2018 Consultor de Segurança da Informação (ISO/IEC 27001:2013) Global Score Lda., consultoria de gestão.
Mar 2012 — Mai 2017 Administrador / Engenheiro de Sistemas Ative Lda., higiene e segurança industrial, 34 pessoas. Windows Server, SQL Server, SSRS, Primavera ERP, redes, helpdesk.
Jun 2007 — presente Administrador de Sistemas (apoio contínuo) Cópia Igual Lda., tipografia.
Jan 2006 — presente Freelancer de TI Atualizações de sistemas e servidores, redes e TI em geral.
Jan 1997 — Set 2011 Apoio ao Cliente e Produção Gráfica CIAU Lda., tipografia. AutoCAD e ferramentas profissionais Adobe.

O meu percurso profissional e o meu trabalho de sistemas correram em paralelo. Os empregos pagavam as contas e mantinham-me próximo das operações reais — clientes, escalamentos, desempenho de equipa, pressão diária de serviço. Os sistemas deste portefólio são o que construí em paralelo com essas funções e depois delas, e são a demonstração de que a capacidade ultrapassou os empregos. Desde abril de 2026 faço este trabalho a tempo inteiro, como freelancer sob a marca Quiet Systems e, para a equipa certa, numa função onde os dois convergem.

As ferramentas, dados e processos internos da Teleperformance não são descritos aqui nem no portefólio, em cumprimento de obrigações de confidencialidade.

Formação — ISO/IEC 27001:2013 Segurança da Informação (IPAC, 2017) · Microsoft MCSE/MCSA e Cisco CCNA (Galileu, 2006) · Técnico de Audiovisuais (2001). Línguas — Português nativo · Inglês C2 leitura e compreensão oral, C1 escrita · Francês C2 leitura e compreensão oral, B2 escrita. Autoavaliação QECR.

Onde isto se enquadra

Aprendo fluxos de trabalho depressa e construo em torno daquilo em que um negócio já confia

Aprendo fluxos de trabalho depressa, descubro onde estão os verdadeiros problemas operacionais e construo melhorias cuidadas e úteis em torno das ferramentas em que um negócio já confia. Se tem um negócio e reconhece este tipo de trabalho, a Quiet Systems é a forma como o assumo: primeiro uma auditoria com âmbito definido, depois o sistema. Se está a recrutar para uma equipa onde isto converge — operações, ferramentas internas e um conjunto de IA que precisa de um responsável humano — é essa a competência que transita diretamente.

Entrar em contacto → Quiet Systems →