Sebastian O Rodriguez

Explore Guava AI →

Build for Business Outcomes

I started Guava AI to help real people run their businesses better. As the company grew, that goal became more concrete: build systems that improve how businesses operate.

The work has taken me through retail, distribution, financial services, property management, and other operations where important processes span software, spreadsheets, email, databases, and manual work.

We start with the people running the operation. I ask what is painful, how work moves through the business, where time or information gets lost, and what actually affects the outcome. That gives us a model of the operation before we make decisions about the technology.

Find the Bottleneck

The problem a business notices first is not always the problem worth solving. Repetitive work, unreliable reporting, disconnected data, and slow handoffs are often symptoms of a deeper constraint.

A report that takes hours to prepare might really be a data integration problem. Inventory discrepancies might come from systems that represent the same operation differently. A manual approval might exist because the software lacks the context to make the next step safe.

Finding that underlying constraint matters because automating the symptom can make a bad process faster without making the operation better.

Match the System to the Problem

Once the constraint is clear, I choose the smallest intervention that produces the outcome. The answer might be an integration, deterministic automation, a better data model, AI interpretation, or an agent that can act across a workflow.

flowchart LR
    A["Outcome"] --> B["Constraint"]
    B --> C{"Need?"}
    C -->|"Data"| D["Integration"]
    C -->|"Rules"| E["Automation"]
    C -->|"Judgment"| F["AI"]
    C -->|"Actions"| G["Agent"]

I do not treat AI or autonomy as the destination. A technically ambitious solution is not inherently better. If a spreadsheet solves the problem cleanly, there is no reason to build an agent.

The business outcome determines the technology, not the other way around.

Build Around Reality

Businesses are rarely greenfield systems. Their operations already depend on ERP and POS software, databases, spreadsheets, APIs, email, and processes accumulated over years.

Guava AI works with that reality. We connect systems that need to communicate, preserve what already works, and change the parts creating the bottleneck. Good software has to understand the operation it is entering, not assume it can replace it.

Draw the Right Boundaries

This work changed how I think about AI engineering. Models are useful because they handle ambiguity, interpretation, and judgment. Those strengths do not make them the right tool for every part of a system.

If the rules are known, I prefer deterministic code. If the input requires judgment, I use a model. If the underlying data is unreliable, I fix that first. If an agent can take actions, I strengthen the controls around its authority.

The pattern is consistent: use intelligence where judgment creates leverage, and deterministic systems where correctness, state, and control matter.

Automate What Matters

Building Guava AI has made me less interested in how much of a system can be automated and more interested in whether the intervention improves the operation.

Good automation starts with understanding the business well enough to know what should change. Some problems need AI. Others need conventional software, a better process, or no new technology at all.

The best automation is not the system that automates the most. It is the one that removes the right constraint.

Explore Guava AI →

Read the Full Guava OS Article →

The Model Is Only Part of the System

Coding agents are good at bounded implementation tasks. The problem changes when I ask them to do substantial work autonomously. Tasks depend on one another. Workers need different context. Parallel changes can collide. Finished code still needs to be verified before it moves forward.

At that point, improving the prompt is not enough. The engineering problem moves into the system around the agent.

Build the Harness

I built Guava OS to control that surrounding system. Work starts with a deliberate plan, decomposes into bounded tasks with explicit dependencies, then fans out to isolated workers with the context and skills required for each task.

The objective is not maximum parallelism. It is safe parallelism. Independent work can run concurrently while dependencies, ownership, and state remain explicit.

Separate Execution From Authority

An agent finishing a task does not make the task complete. Guava OS sends work through deterministic checks and review before it can be promoted. The worker that writes the code does not decide whether that code should ship.

That separation lets me increase execution autonomy without giving agents unrestricted delivery authority.

What I Learned

More capable agents do not reduce the need for engineering controls. They increase it. As execution becomes more autonomous, planning, context, isolation, validation, and promotion become more important.

The more autonomy I give the agent, the stronger I want the system around it to be.

Read the Full Guava OS Article →

Explore Guava BI on GitHub →

Same Problem, Different Businesses

At Guava AI, I worked with businesses across food service, insurance, financing, manufacturing, and distribution. Different industries, same problem: plenty of data with no easy way to understand it.

Their data lived across ERPs, POS systems, spreadsheets, databases, and manual processes. Reporting often depended on SQL, limited dashboards, or manual reconciliation. The result was stale information, repetitive work, and a growing gap between what was happening in the business and what decision-makers could see.

Much of my work involved connecting those systems and improving their data pipelines. That solved part of the problem, but another bottleneck remained. People still needed a better way to explore and understand the data. Guava BI grew out of that work.

Make the Data Easier to Use

Better pipelines do not automatically produce better decisions. People still need to find the right dashboard, understand its structure, and know which dimensions or metrics will answer their questions.

Natural language offers a more flexible interface. A manager should be able to ask, “What inventory needs attention this week?” without knowing where the data lives or how the reporting system represents it.

That creates a harder engineering question. How do you make the interface flexible without making the numbers probabilistic?

Separate Meaning From Math

Guava BI separates interpretation from calculation.

flowchart LR
      A["Data"] --> B["Profile"]
      B --> C["Interpret"]
      C --> D["Validate"]
      D --> E["Model"]
      E --> F["Compute"]
      F --> G["Interfaces"]

AI handles the ambiguous work. It interprets unfamiliar schemas, maps fields to business concepts, and determines what a user is asking. The system validates those interpretations before they reach the analytical layer.

Once the meaning is established, code takes over. It calculates metrics, trends, and operational signals deterministically while preserving a traceable path back to the source data.

One System, Multiple Interfaces

Dashboards, conversational analysis, and recommendations all draw from the same analytical layer. Natural language does not create a second source of truth. It provides another way to interrogate the existing one.

The model interprets the question. The application supplies the numbers.

What I Learned

Guava BI reinforced an idea that now shapes how I build AI systems. Uncertainty at the interface does not require uncertainty throughout the system.

Models are useful when meaning requires judgment. Once the meaning is clear, deterministic software should enforce the rules.

For Guava BI, the principle is simple: AI interprets, code calculates.

Explore Guava BI on GitHub →

Explore PMLaD on GitHub →

Model the Operation

I built PMLaD around one principle: model the operation first, then build the interface around it. Property management is a network of connected workflows: Owners, managers, tenants, leases, payments, maintenance, contractors, expenses, and recurring work all affect one another.

When those workflows live across spreadsheets, messages, email, and separate tools, context breaks apart. A maintenance request loses its connection to the tenant who reported it. A payment needs to be reconciled with a lease. A repair becomes an expense that affects property performance.

Keep Context Connected

PMLaD connects workflows through a shared domain model. Properties contain units. Units connect to tenants and leases. Maintenance creates work, costs, and history. Payments affect balances. Tasks and expenses feed into property performance.

These relationships matter more than any individual screen. Once the system understands how the pieces connect, information can move through the operation without being repeatedly copied or reconstructed.

flowchart LR
      A["Property"] --> B["Units"]
      B --> C["Tenants"]
      A --> D["Maintenance"]
      D --> E["Tasks & Costs"]
      C --> F["Payments"]
      E --> G["Performance"]
      F --> G
      G --> H["Portfolio"]

Make Authority Structural

Connecting the operation creates another requirement. Not everyone should see or control everything.

Owners, managers, tenants, and field workers share the system with different responsibilities. PMLaD treats those boundaries as architecture, not interface logic.

PostgreSQL Row Level Security enforces tenant isolation close to the data. Access depends on the actor, their scope, and the action they are attempting. The application builds workflows on top of those rules instead of carrying the full burden of enforcing them.

Earn the Automation

Automation becomes useful when the underlying system already knows what exists, how entities relate, who has authority, and where each workflow stands.

AI can classify a maintenance request, summarize activity, or recommend a next action. It cannot compensate for a system that does not reliably know which tenant, unit, property, or workflow that action belongs to.

The quality of the automation depends on the quality of the software underneath it.

What I Learned

PMLaD reinforced the value of modeling the domain before optimizing individual workflows. Good abstractions preserve context. Strong authorization creates safe boundaries. Connected data creates leverage.

Before making a system intelligent, make sure it understands the operation.

Explore PMLaD on GitHub →

Explore RoutineMe on GitHub →

Why I Built It

I tracked my meals with MyFitnessPal for more than a year. It worked, but accurate logging was tedious. A basic chicken-and-broccoli dinner meant weighing several ingredients, finding the correct entries, entering quantities, and checking the result.

Even after I got faster, logging each meal took 5–7 minutes. At 3 meals a day, that can add up to roughly 90 hours a year.

I wanted to reduce that to less than 1 minute per meal without giving up useful accuracy. I build software for a living, so I built RoutineMe.

Rethinking Meal Logging

The core product decision was simple: spend less time entering data and more time using it.

RoutineMe lets me log food the way I naturally think about it. I can enter an exact weight when I have one, describe something loosely, or use an image when that’s easier. The system turns that input into a structured entry that I can review before saving.

It also uses previously confirmed entries as context. If I eat the same food again, RoutineMe can reuse what it already knows instead of starting from scratch.

Once meals are stored consistently, the history becomes more useful. I can quickly see what I have been eating and, over time, ask better questions about patterns, habits, and gaps in my diet. The goal is to make tracking feel less like data entry and more like a tool for staying consistent.

Where AI Stops

The most important engineering decision was deciding how much authority to give the model. I use AI to interpret ambiguous input, then hand the result to deterministic application code.

flowchart LR
      A["Loose input"] --> B["Interpret"]
      B --> C["Proposal"]
      C --> D["Confirm"]
      D --> E["Deterministic write"]

The model never gets arbitrary control over application state. I define the boundary with TypeScript and Zod schemas, then route state changes through a typed action path. The AI handles the probabilistic problem; application code handles validation and execution.

This separation makes the system easier to test, debug, and change. I can evaluate model behavior independently, validate actions before execution, and swap models or prompts without rewriting the application’s core rules. It also avoids spending tokens on work that ordinary code can perform faster and more predictably.

What I Learned

RoutineMe changed how I think about human-AI interaction. Natural language can be an input method without turning the product into a chatbot.

The model can absorb ambiguity, translate it into something the software understands, and then get out of the way. That has become a useful rule for how I build AI systems: use models where judgment is valuable; use deterministic software where the rules are known.

Explore RoutineMe on GitHub →