Gabriel Paz

Software engineer · Solution architecture · Buenos Aires

I design systems and ways of working that keep judgment visible.

I am Gabriel Paz, a hands-on software engineer and solution architect withfive years of verifiable professional experience. I work where AI workflows, distributed systems, product delivery, and technical teams need a shared operating model — not another layer of hidden complexity.

Core stack
C#/.NET, Azure, APIs, distributed systems
AI practice
LangGraph, RAG, latency and observability
Working style
Architecture + implementation + team enablement
Gabriel's systems operating modelA system diagram connecting real constraints to working software, evidence and team capability.REALCONSTRAINTSusers · risk · contextARCHITECTUREDECISIONSboundaries · trade-offsWORKINGSYSTEMdelivery · reliabilityHUMAN +TECHNICALjudgment stays visibleEVIDENCEobservability · feedbackTEAM CAPABILITYcontext · ownership · learning
The work is never only the code: it is the decision system around the code.

Selected directions

The situations I am built for.

I am at my best when a team has to make a technical system clearer, safer, more useful, and easier to evolve at the same time.

AI systems where latency, privacy, and human judgment all matter.

Architecture and workflow design for sensitive-domain assistants, with clear action boundaries, traceability, observability, and human review paths.

  • AI workflows
  • LangGraph
  • Observability
  • Human review

Integrations and back-office systems that do not hide the hard parts.

API boundaries, permissions, workflow states, auditability, and practical delivery decisions for business-critical systems.

  • C#/.NET
  • APIs
  • Distributed systems
  • Audit

A way of working that makes AI assistance inspectable instead of magical.

I build the context, evidence, and orchestration layers that help teams use AI without losing technical judgment or accountability.

  • Context systems
  • Evidence
  • Team enablement
  • Quality

Public projects and tools

The projects that make my way of working concrete.

Each one solves a different part of the same problem: make context clearer, decisions safer, and technical work easier to carry forward. They are public, evidence-bounded views — not confidential case studies in disguise.

01

Product ecosystem

Contedi / Tedi — personal context that stays useful because it stays inspectable.

Contedi is where I explore products that turn everyday capture into retraceable context. Tedi Notas gives that work a public writing surface; Tedi brings notes, sources, recall, uncertainty, and user correction together so personal knowledge is not treated as a black box.

  • Product systems
  • .NET
  • Source attribution
  • Human correction

A public product narrative. It intentionally excludes private users, customer data, and unverified product claims.

Visit Contedi
02

Team operating model

mi-wiki + an agentic execution layer — make the way of working as intentional as the system.

The wiki holds shared reality: decisions, constraints, evidence, and what is still open. The execution layer turns that context into bounded work with ownership, stop conditions, review points, and human judgment where it matters.

  • Shared context
  • AI adoption
  • Traceability
  • Human gates

A public method and criteria case. No client, team, or operating details are disclosed.

Explore mi-wiki
03

Developer tooling

mi-lsp — give coding agents a governed sense of place before they change code.

A local CLI for finding relevant code, reading exact ranges, following repository relationships, and starting from canonical documentation. It replaces blind repository discovery with focused, inspectable context.

  • C# / TypeScript
  • Context navigation
  • Docs-first
  • Guardrails

Public repository material; private project context and infrastructure details stay out of this profile.

Explore mi-lsp
04

Data tooling

db-cli — direct database work, with the guardrails inside the tool.

A terminal-first tool for PostgreSQL and SQL Server that keeps connection configuration explicit, supports structured output, and makes writes and migrations deliberate rather than accidental.

  • PostgreSQL
  • SQL Server
  • SQL Guard
  • Explicit writes

Public repository material. It describes the tool's safeguards, not access to any production database.

Explore db-cli

Browse the wider body of public work on GitHub.

Teaching the new way of working

AI adoption is not a prompt library. It is a team capability.

I help teams move beyond individual prompting toward coordinated AI-assisted delivery: shared context, explicit ownership, evidence, and decisions that remain inspectable. The goal is not more automation; it is a team that can make better technical choices together.

Layer 01

The wiki: a shared reality the team can interrogate

It gives decisions, constraints, evidence, and open questions a durable home. Instead of rebuilding the same context in every conversation, people can inspect it, challenge it, and extend it together.

Layer 02

The AE layer: turn shared context into bounded work

It gives each task an explicit scope, owner, stop condition, evidence route, and human decision point. AI-assisted delivery becomes faster without turning judgment, quality, or accountability invisible.

Layer 03

The capability: a team that can coordinate, not just prompt

This is what I teach: move from isolated AI use toward a shared practice where people can find context, challenge decisions, delegate safely, and learn from the evidence the work produces.

How I work

Start with what has to be true, then make it real.

  1. 01

    Architecture that respects constraints

    I frame the system around the real constraints first: users, reliability, privacy, integration boundaries, and the decisions that must remain visible.

  2. 02

    Hands-on delivery

    I stay close to the implementation layer: C#/.NET, APIs, distributed workflows, observability, and AI-assisted development where it is genuinely useful.

  3. 03

    Teams that can carry the system

    I help turn a good technical direction into a working rhythm: shared context, smaller decisions, explicit ownership, and room for people to learn.

Let’s talk

If the challenge needs both sound engineering and a team that can own it, I would like to hear about it.

paz.fgabriel@gmail.com