Entrepreneurship Live – Agent Brasil (Sandeco)

Hello, innovation enthusiasts and future entrepreneurs! If you dream of creating your own startup or improving your current project, this article is for you. Recently, the Sandeco channel promoted another unmissable episode of the **"Agent Brasil"** program, focused on startups, with hosts Diego and Jorge Fela. The live session featured special participation from **Thiago Peraro**, who brought valuable and practical insights on how to validate and build a startup.

## The Startup Journey: From Idea to Success

The Sandeco startup program aims to be a complete roadmap for those who want to set up a startup or understand how it works. This live session with Thiago Peraro was the second part of a series dedicated to the theme, focusing on **"fundamentals and entrepreneurial mindset"**. The great differentiator is that the speakers are people who "got their hands dirty", faced pains and successes in creating their own startups, offering practical and experiential knowledge.

### Who is Thiago Peraro?

Thiago Peraro, the distinguished guest of the live session, is the founder of **Clívia** (an SDR that supports medical clinics), acts in the leadership of the entrepreneurs group at **Magnatas Hub Goiás**, participates in **Go IA** (AI community in Goiás), is a researcher at **CEIA at UFG**, and a Computer Science student. Additionally, he coordinates the AI team of the **"Sobre Vidas"** project, a tool for tracking and monitoring oral cancer risk, and has experience as a backend programmer. A robust resume that ensures authority in his statements.

## After All, What is a Startup?

Thiago started by defining a startup according to Sebrae: a group of people seeking a **repeatable and scalable business model**, working under **extreme uncertainty** conditions. Unlike a traditional company, a startup is linked to innovation, new technologies, research and development. "Extreme uncertainty" arises when you cannot do traditional market research, as you are creating a new market from a pain that only you saw.

Startups go through stages:

1. **Ideation:** Discussion of a potentially innovative business.
2. **MVP (Minimum Viable Product):** Validation with the market.
3. **Traction:** After finding what the market wants and accepts.
4. **Growth and Scale:** Business expansion.

Each phase requires attention and specific processes to deal with customers, employees, and the company.

## The Power of Business Model Canvas (BMC)

To transform an idea into a business, Thiago presented the **Business Model Canvas (BMC)**, a framework that helps list the essential components of a business model:
![Business Model Canvas example](/images/business-model-canvas.webp)

- **Key Partnerships:** Who are your partners (e.g., payment processors, map APIs for Uber).
- **Key Activities:** What the company does to operate and survive (e.g., acquisition marketing, platform development).
- **Key Resources:** What you use (e.g., money for paid traffic).
- **Value Proposition:** The problem you solve for the customer.
- **Customer Relationships:** How you relate (e.g., self-service, reviews, feedback, support).
- **Channels:** How you promote and distribute the product (e.g., website, app, WhatsApp).
- **Customer Segments:** Who you are solving the problem for. The more niche, the better, seeking the **ICP (Ideal Customer Profile)**.
- **Revenue Streams:** Where the money comes from.
- **Cost Structure:** What the expenses are.

The Sandeco channel provides a link to download the BMC, encouraging iteration and recording of learnings.

## Is Your Company a Startup or Traditional? The Checklist

To know if your business is a startup, Thiago presented a checklist:

1. **Scale Thesis:** Can you grow 10x without multiplying the team and cost at the same rate?
2. **Repeatability:** Do you deliver the same value in a standardized or automated way?
3. **Large Market:** Is your market large enough for scale? It's crucial to calculate **TAM, SAM, and SOM** for investors.
4. **Growth Engine:** Do you have a validated channel that allows organic acceleration? The **Customer Acquisition Cost (CAC)** must be less than the **Lifetime Value (LTV)**.
5. **Experiment Pace:** Do you test, measure, and iterate every week until reaching **Product Market Fit**?

If you meet three or more of these points, you can classify yourself as a startup.

## One Person Business (OPB): The Trend of the AI Era

The Artificial Intelligence era has driven the **One Person Business (OPB)** trend, where a single person runs the entire business, facilitated by AI agents to automate tasks. However, Thiago warns that the complexity of a company still exists and there is a limit to what one person can do alone.

## Google's Sprint Method: Fail Fast to Learn More

The Sprint method, developed at Google, is a 7-day methodology to test ideas. The philosophy is **"fail fast"** to learn and iterate.

- **Day 1 (Map):** Brainstorm all possible problems.
- **Day 2 (Define):** Choose a main problem to attack.
- **Day 3 (Sketch):** Sketch the solution to the defined problem.
- **Day 4 (Execute):** Build the solution.
- **Day 5 (Prototype):** Create a prototype (low or high fidelity).
- **Day 6 (Test):** The customer uses the MVP for validation.
- **Day 7 (Learn):** The team meets to analyze the results.

## Types of MVP: Validating Your Idea in Different Ways

The MVP doesn't have a single form. Thiago presented several types:

- **Smoke Test MVP:** Create a facade of a product that doesn't exist yet (e.g., landing page) to measure interest.
- **Video MVP:** A video that demonstrates the value proposition before the product is functional (e.g., Dropbox).
- **Concierge MVP:** The entrepreneur manually performs the service that the product proposes to automate.
- **Wizard of Oz:** The user thinks the technology is working, but there's a person operating behind it.
- **Piecemeal:** Build the product by integrating third-party tools (e.g., WordPress, APIs, open source).
- **Single Feature MVP:** Focus on building and launching only the main feature that solves the most critical problem.

## The MVP Experiment Canvas: A Guide for Precise Testing

To go beyond BMC and Sprint, Thiago presented the **MVP Experiment Canvas**, a tool to plan and document MVP experiments. It helps note hypotheses, success metrics, results, and next steps, allowing iteration based on concrete data.

## The Secret Tool: Custom GPT for Entrepreneurs!

Thiago Peraro presented a powerful tool developed by him: a **custom GPT that acts as a copilot for entrepreneurs**. Trained with all the knowledge from the live session, it serves as an assistant to help you set up your MVP Experiment Canvas. Just paste your BMC and ask for guidance on your next iteration.

## Conclusion

The Sandeco channel live session was a true mentorship, a "gold mine" of knowledge shared for free. From the definition of startup, through tools like BMC and Sprint, to MVP types and TRL, each topic was addressed with depth and practical examples. The cherry on top was the delivery of the custom GPT, a tool that consolidates all this learning and makes it accessible to any entrepreneur.

Follow Thiago Peraro on LinkedIn and Instagram for more insights. And don't forget to use the GPT and the Canvas models mentioned – they were created to boost your entrepreneurial journey!


Unlocking the Startup World: Key Insights and Tools from Sandeco's Agent Brasil

The Sobrevidas project represents a milestone in my career as a researcher and a powerful example of how artificial intelligence can be applied to solve real problems and save lives. As the leader of the project's AI team — an undergraduate research project at UFG, where I am completing my Computer Science degree — I had the privilege of coordinating the development of a solution that received national recognition.

## The Problem: Late Diagnosis of Oral Cancer

Oral cancer is one of the most common neoplasms in Brazil, but it is frequently diagnosed in advanced stages. This happens mainly due to:

- **Lack of knowledge** among the population about symptoms
- **Limited access** to specialists
- **Delays** in the referral system
- **Absence of systematic screening** in primary care

Our mission was clear: develop an AI solution that could democratize access to early diagnosis through the SUS.

## The Solution: Intelligent Chatbot Integrated with SUS

### System Architecture

We developed a conversational chatbot that uses advanced Natural Language Processing (NLP) techniques. Each conversation runs through three chained layers:

1. **Interpretation** — the language model reads the patient's account in colloquial Portuguese and extracts the symptoms being described.
2. **Risk classification** — the extracted symptoms, together with behavioral and demographic factors, feed the model that assigns an urgency level.
3. **Referral** — the urgency level determines the recommendation and, when warranted, triggers the integration with the public health network.

### Main Features

**1. Intelligent Screening**
- Symptom collection through natural conversation
- Analysis of behavioral risk factors
- Automatic classification of urgency level

**2. SUS Integration**
- Automatic appointment scheduling
- Referral to specialists
- Patient tracking in the network

**3. Education and Prevention**
- Personalized prevention information
- Alerts for risk groups
- Targeted educational campaigns

## Technical Challenges Overcome

### 1. Medical Natural Language Processing

The hardest part was teaching the model how Brazilians actually describe a symptom. Nobody shows up saying "I present an ulcer on my oral mucosa" — they say "I've got a sore in my mouth that won't heal". We had to map that colloquial vocabulary onto clinical terminology:

| How the patient says it | Clinical term |
| --- | --- |
| sore in the mouth | oral ulcer, mucosal lesion |
| lump in the neck | palpable lymph node, adenopathy |
| hoarseness | dysphonia |
| sore throat | odynophagia |

This mapping is not a fixed table: regional wording varies a lot across Brazilian states, and much of the research work went into widening that coverage without producing false positives.

### 2. Risk Classification Model

We created a scoring system that combines three groups of factors, each with its own weight:

- **Behavioral** — smoking and drinking, weighted by length of exposure rather than a plain yes or no. Twenty years of cigarettes does not carry the same weight as two.
- **Reported symptoms** — every symptom extracted from the conversation contributes a weight, and certain combinations raise the risk more than the sum of their parts.
- **Demographic** — age bracket and other epidemiological markers for oral cancer.

The total lands in a band that defines the course of action: preventive guidance, follow-up, or priority referral. Calibrating those weights was the most delicate work — in cancer screening a false negative costs far more than a false positive, and the model has to err on the safe side.

### 3. Integration with SUS Systems

The biggest challenge was integrating our solution with the existing SUS infrastructure:

- **Legacy APIs** with limited documentation
- **Strict security protocols** for health data
- **Regional variations** in information systems
- **LGPD compliance** for sensitive data

## Results and Impact

### Performance Metrics

During testing period:

- **95% accuracy** in high-risk case classification
- **78% reduction** in initial screening time
- **89% user satisfaction** with the experience
- **67% increase** in preventive consultation appointments

### National Recognition

Our research was recognized with the **best paper award in Brazil at SBCAS 2025** (Brazilian Symposium on Computing Applied to Health), validating the scientific and social impact of the project.

## Technologies Used

**Backend** — Python 3.9, FastAPI, SQLAlchemy and Celery for asynchronous processing.

**AI/ML** — spaCy for Portuguese NLP, Transformers (BERT Portuguese) and scikit-learn for classification, TensorFlow for the neural networks.

**Integration** — REST APIs over the FHIR health data standard, OAuth 2.0 and Docker.

**Infrastructure** — AWS, PostgreSQL for structured data, Redis for cache and queues, Nginx as reverse proxy.

## Lessons Learned

### 1. Importance of Natural Language

We discovered that the ability to converse naturally with the system was crucial for user adoption. People describe symptoms in very varied and colloquial ways.

### 2. Need for Medical Validation

All functionality was validated by oncologists and head and neck surgeons, ensuring recommendations were aligned with medical protocols.

### 3. Ethics in AI for Health

We implemented rigorous safeguards:
- Transparency in algorithm decisions
- Continuous bias auditing
- Informed user consent
- Protection of sensitive data

## Social Impact

The Sobrevidas project demonstrates how AI can be a powerful tool to democratize access to health. Main impacts:

- **Universal access**: Available to anyone with a smartphone
- **Early diagnosis**: Reduction in time between symptoms and diagnosis
- **Health education**: Reliable prevention information
- **SUS optimization**: Better resource allocation

## Next Steps

The success of Sobrevidas opened doors for expansion:

1. **Other cancer types**: Adaptation for different neoplasms
2. **National scale**: Implementation in more states
3. **Advanced features**: Image analysis and exams
4. **International partnerships**: Application in other countries

## Final Reflections

Leading the Sobrevidas project was a transformative experience that solidified my conviction about the power of AI applied for social good. It's not enough to develop advanced technology; we must ensure it reaches those who need it most.

As a CNPq researcher and Clivia founder, I continue applying the lessons from Sobrevidas in new projects, always focused on social impact and technological ethics.

The national recognition at SBCAS 2025 is just the beginning. Our mission is to continue developing AI solutions that save lives and improve the quality of Brazilian public health.

---

*The Sobrevidas project is developed at UFG as an undergraduate research project with a CNPq scholarship. For more information about research collaborations or solution application, contact through [LinkedIn](https://www.linkedin.com/in/thiago-peraro/).*


Sobrevidas Project: AI That Saves Lives in the SUS

Docker has become essential in modern development, but many developers stay with the basics. In this post, I share advanced techniques I use daily to optimize workflows and improve efficiency.

## Multi-Stage Builds: The Game Changer

Multi-stage builds allow creating smaller and more secure images:

```dockerfile
# Build stage
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

COPY . .
RUN npm run build

# Production stage
FROM node:18-alpine AS production
WORKDIR /app

# Copy only production dependencies
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./

EXPOSE 3000
CMD ["node", "dist/index.js"]
```

### Result: 800MB → 150MB

## Advanced Docker Compose

### 1. Profiles for Different Environments

```yaml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis
    profiles: ["app"]

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    profiles: ["app", "db-only"]

  redis:
    image: redis:7-alpine
    profiles: ["app", "cache"]

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app
    profiles: ["production"]

volumes:
  postgres_data:
```

Usage:

```bash
# Development
docker-compose --profile app up

# Database only for testing
docker-compose --profile db-only up

# Production with proxy
docker-compose --profile production up
```

### 2. Override Files for Environments

```yaml
# docker-compose.override.yml (development)
version: '3.8'
services:
  app:
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
    command: npm run dev
```

```yaml
# docker-compose.prod.yml (production)
version: '3.8'
services:
  app:
    restart: unless-stopped
    environment:
      - NODE_ENV=production
    deploy:
      resources:
        limits:
          memory: 512M
        reservations:
          memory: 256M
```

## Performance Optimizations

### 1. Smart Layer Caching

```dockerfile
FROM node:18-alpine

WORKDIR /app

# Copy only package.json first (caching)
COPY package*.json ./
RUN npm ci --only=production

# Copy code after
COPY . .

# Build only if code changed
RUN npm run build

EXPOSE 3000
CMD ["npm", "start"]
```

### 2. Optimized .dockerignore

```dockerignore
# Dependencies
node_modules
npm-debug.log

# Development files
.git
.gitignore
README.md
.env
.nyc_output
coverage
.npm

# Local build files
dist
build

# IDE files
.vscode
.idea
*.swp
*.swo

# Logs
logs
*.log

# Cache
.cache
.parcel-cache
```

## Development with Hot Reload

### Development Dockerfile:

```dockerfile
FROM node:18-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

# Install nodemon globally
RUN npm install -g nodemon

COPY . .

EXPOSE 3000

# Use nodemon in development
CMD ["nodemon", "--legacy-watch", "src/index.js"]
```

### Docker Compose with volumes:

```yaml
version: '3.8'
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    ports:
      - "3000:3000"
    volumes:
      - .:/app
      - /app/node_modules  # Anonymous volume for node_modules
    environment:
      - NODE_ENV=development
```

## Health Checks and Monitoring

```dockerfile
FROM node:18-alpine

WORKDIR /app
COPY . .
RUN npm install

EXPOSE 3000

# Health check
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

CMD ["npm", "start"]
```

### Implementing health endpoint:

```javascript
// src/health.js
app.get('/health', (req, res) => {
  const healthcheck = {
    uptime: process.uptime(),
    message: 'OK',
    timestamp: Date.now(),
    checks: {
      database: checkDatabase(),
      redis: checkRedis(),
      memory: process.memoryUsage()
    }
  };

  res.status(200).json(healthcheck);
});
```

## BuildKit and Advanced Features

### 1. Parallel Builds

```dockerfile
# syntax=docker/dockerfile:1
FROM node:18-alpine AS base
WORKDIR /app
COPY package*.json ./

FROM base AS dependencies
RUN npm ci --only=production

FROM base AS build
RUN npm ci
COPY . .
RUN npm run build

FROM dependencies AS final
COPY --from=build /app/dist ./dist
CMD ["node", "dist/index.js"]
```

### 2. Cache Mounts

```dockerfile
# syntax=docker/dockerfile:1
FROM node:18-alpine

WORKDIR /app
COPY package*.json ./

# Mount cache for npm
RUN --mount=type=cache,target=/root/.npm \
    npm ci --only=production

COPY . .
CMD ["npm", "start"]
```

## Security in Containers

### 1. Non-root User

```dockerfile
FROM node:18-alpine

# Create non-root user
RUN addgroup -g 1001 -S nodejs
RUN adduser -S nextjs -u 1001

WORKDIR /app
COPY . .
RUN npm ci --only=production

# Change ownership of files
RUN chown -R nextjs:nodejs /app

# Switch to non-root user
USER nextjs

EXPOSE 3000
CMD ["npm", "start"]
```

### 2. Vulnerability Scanning

```bash
# Image scan
docker scan myapp:latest

# Using Trivy
trivy image myapp:latest

# CI/CD integration
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image myapp:latest
```

## Automation Scripts

### Makefile for Docker:

```makefile
.PHONY: build run test clean

IMAGE_NAME = myapp
VERSION = $(shell git rev-parse --short HEAD)

build:
	docker build -t $(IMAGE_NAME):$(VERSION) .
	docker tag $(IMAGE_NAME):$(VERSION) $(IMAGE_NAME):latest

run:
	docker-compose up -d

test:
	docker run --rm $(IMAGE_NAME):latest npm test

clean:
	docker system prune -f
	docker volume prune -f

push:
	docker push $(IMAGE_NAME):$(VERSION)
	docker push $(IMAGE_NAME):latest

dev:
	docker-compose -f docker-compose.yml -f docker-compose.dev.yml up

prod:
	docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d
```

## Debugging in Containers

### 1. Debug with Node.js

```dockerfile
FROM node:18-alpine

WORKDIR /app
COPY . .
RUN npm install

# Expose debug port
EXPOSE 3000 9229

# Command with debug enabled
CMD ["node", "--inspect=0.0.0.0:9229", "src/index.js"]
```

### 2. Docker Compose for debug:

```yaml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
      - "9229:9229"  # Debug port
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
```

## Monitoring and Logs

### 1. Centralized Logging

```yaml
version: '3.8'
services:
  app:
    build: .
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

  fluentd:
    image: fluent/fluentd:latest
    volumes:
      - ./fluent.conf:/fluentd/etc/fluent.conf
    depends_on:
      - elasticsearch
```

### 2. Metrics with Prometheus

```yaml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
      - "9090:9090"  # Metrics

  prometheus:
    image: prom/prometheus
    ports:
      - "9091:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
```

## Conclusion

Docker offers much more than basic containerization. With these advanced techniques, you can:

- **Reduce image size** significantly
- **Speed up builds** with smart caching
- **Improve security** with proper practices
- **Automate workflows** for development and deployment
- **Monitor applications** effectively

The investment in learning these techniques pays off quickly in productivity and code quality.

---

*Want to discuss more about Docker and DevOps? Find me on [LinkedIn](https://www.linkedin.com/in/thiago-peraro/) or check my projects on [GitHub](https://github.com/tperaro).*


Docker for Developers: Beyond the Basics

Next.js 14 brought a revolution with Server Actions, allowing us to execute code on the server directly from React components. In this post, I explore how this functionality is changing full-stack development.

## What Are Server Actions?

Server Actions are asynchronous functions that run on the server and can be called directly from React components, either client-side or server-side. They eliminate the need to create separate API routes for many operations.

```typescript
'use server'

import { revalidatePath } from 'next/cache'
import { db } from '@/lib/db'

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string
  const content = formData.get('content') as string

  const post = await db.post.create({
    data: { title, content }
  })

  revalidatePath('/posts')
  return { success: true, postId: post.id }
}
```

## Practical Use Cases

### 1. Forms Without JavaScript

Server Actions work even with JavaScript disabled:

```tsx
import { createPost } from '@/actions/posts'

export default function CreatePostForm() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="Post title" required />
      <textarea name="content" placeholder="Content" required />
      <button type="submit">Create Post</button>
    </form>
  )
}
```

### 2. Optimized Database Operations

With Server Actions, we can perform complex operations on the server:

```typescript
'use server'

export async function updateUserProfile(userId: string, data: ProfileData) {
  // Server-side validation
  const validatedData = profileSchema.parse(data)

  // Multiple operations in one transaction
  await db.$transaction(async (tx) => {
    await tx.user.update({
      where: { id: userId },
      data: validatedData
    })

    await tx.activityLog.create({
      data: {
        userId,
        action: 'PROFILE_UPDATE',
        details: validatedData
      }
    })
  })

  revalidatePath(`/profile/${userId}`)
}
```

### 3. File Upload

File handling becomes much simpler:

```typescript
'use server'

import { put } from '@vercel/blob'

export async function uploadImage(formData: FormData) {
  const file = formData.get('image') as File

  if (!file) {
    throw new Error('File is required')
  }

  const blob = await put(file.name, file, {
    access: 'public',
  })

  // Save reference in database
  await db.image.create({
    data: {
      url: blob.url,
      filename: file.name,
      size: file.size
    }
  })

  return { url: blob.url }
}
```

## Integration with Hooks

For more complex interactions, we can use hooks:

```tsx
'use client'

import { useFormStatus } from 'react-dom'
import { createPost } from '@/actions/posts'

function SubmitButton() {
  const { pending } = useFormStatus()

  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Creating...' : 'Create Post'}
    </button>
  )
}

export default function PostForm() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="Title" />
      <textarea name="content" placeholder="Content" />
      <SubmitButton />
    </form>
  )
}
```

## Error Handling

Server Actions have native support for error handling:

```typescript
'use server'

export async function deletePost(postId: string) {
  try {
    const post = await db.post.findUnique({
      where: { id: postId }
    })

    if (!post) {
      return { error: 'Post not found' }
    }

    await db.post.delete({
      where: { id: postId }
    })

    revalidatePath('/posts')
    return { success: true }

  } catch (error) {
    console.error('Error deleting post:', error)
    return { error: 'Internal server error' }
  }
}
```

## Validation with Zod

Combining Server Actions with Zod for robust validation:

```typescript
'use server'

import { z } from 'zod'

const postSchema = z.object({
  title: z.string().min(1, 'Title is required').max(100),
  content: z.string().min(10, 'Content must have at least 10 characters'),
  tags: z.array(z.string()).optional()
})

export async function createPost(formData: FormData) {
  const rawData = {
    title: formData.get('title'),
    content: formData.get('content'),
    tags: formData.getAll('tags')
  }

  const validationResult = postSchema.safeParse(rawData)

  if (!validationResult.success) {
    return {
      error: 'Invalid data',
      fieldErrors: validationResult.error.flatten().fieldErrors
    }
  }

  const { title, content, tags } = validationResult.data

  const post = await db.post.create({
    data: { title, content, tags }
  })

  revalidatePath('/posts')
  redirect(`/posts/${post.id}`)
}
```

## Performance Optimizations

### 1. Smart Revalidation

```typescript
'use server'

export async function updatePost(postId: string, data: PostData) {
  await db.post.update({
    where: { id: postId },
    data
  })

  // Revalidate only necessary pages
  revalidatePath(`/posts/${postId}`)
  revalidatePath('/posts') // Posts list
  revalidateTag('user-posts') // User's posts
}
```

### 2. Data Streaming

```tsx
import { Suspense } from 'react'

async function PostsList() {
  const posts = await getPosts() // Server Action

  return (
    <div>
      {posts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  )
}

export default function PostsPage() {
  return (
    <Suspense fallback={<PostsSkeleton />}>
      <PostsList />
    </Suspense>
  )
}
```

## Comparison: Before vs After

### Before (API Routes)

```typescript
// app/api/posts/route.ts
export async function POST(request: Request) {
  const body = await request.json()
  const post = await db.post.create({ data: body })
  return Response.json(post)
}

// Client component
const handleSubmit = async (data) => {
  const response = await fetch('/api/posts', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(data)
  })
  const result = await response.json()
}
```

### After (Server Actions)

```typescript
// actions/posts.ts
'use server'
export async function createPost(formData: FormData) {
  const post = await db.post.create({
    data: {
      title: formData.get('title'),
      content: formData.get('content')
    }
  })
  return post
}

// Component
<form action={createPost}>
  {/* inputs */}
</form>
```

## Best Practices

1. **Use TypeScript:** Server Actions greatly benefit from static typing
2. **Always validate:** Never trust client data
3. **Smart revalidation:** Be specific about what to revalidate
4. **Error handling:** Always return clear error states
5. **Progressive Enhancement:** Forms should work without JS

## Conclusion

Next.js 14 Server Actions represent a big step in simplifying full-stack development. They offer:

- **Improved DX:** Less boilerplate and configuration
- **Performance:** Server execution with smart revalidation
- **Progressive:** Works with and without JavaScript
- **Type-safe:** Natural integration with TypeScript

If you haven't tried Server Actions yet, I strongly recommend starting with simple cases like forms and evolving to more complex operations.

---

*Already using Server Actions in your projects? Share your experience on [LinkedIn](https://www.linkedin.com/in/thiago-peraro/) or check more technical content on my [GitHub](https://github.com/tperaro).*


Next.js 14 and Server Actions: Modernizing React Applications

During my time as a senior developer, I had the opportunity to lead a complex migration from a monolithic application to a microservices architecture. In this post, I share the main lessons learned and strategies that worked (and some that didn't).

## The Context

Our monolithic application had grown significantly over 3 years. With more than 100,000 lines of code and a team of 8 developers, we started facing some problems:

- Slow deployments (45+ minutes)
- Difficulty scaling specific features
- High coupling between modules
- Slow development cycles

## The Migration Strategy

### 1. Analysis and Planning

Before starting the migration, we did a detailed analysis of the application, grouping the monolith's tables and routes into the domains they actually served:

- **Authentication** — users, sessions and permissions
- **Products** — catalog, inventory and pricing
- **Orders** — orders, payment and shipping
- **Notifications** — email, SMS and push

The criterion was not the shape of the code but what changed together: if two tables were always modified in the same release, they belonged to the same domain.

### 2. Strangler Fig Pattern

We chose the "Strangler Fig" pattern, extracting services gradually:

```python
# API Gateway configured to route requests
def route_request(path, method):
    if path.startswith('/api/v2/auth'):
        return route_to_auth_service(path, method)
    elif path.startswith('/api/v2/products'):
        return route_to_product_service(path, method)
    else:
        return route_to_legacy_monolith(path, method)
```

## Main Challenges

### 1. Data Management

One of the biggest challenges was dealing with shared data:

```sql
-- Before: shared tables
SELECT u.name, o.total, p.title
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id;

-- After: aggregation via API
// We need to make multiple calls
const user = await userService.getUser(userId);
const orders = await orderService.getUserOrders(userId);
const products = await productService.getProducts(productIds);
```

### 2. Distributed Transactions

We implemented the Saga pattern for transactions that crossed multiple services:

```javascript
class OrderSaga {
  async execute(orderData) {
    try {
      const payment = await this.paymentService.processPayment(orderData.payment);
      const inventory = await this.inventoryService.reserveItems(orderData.items);
      const order = await this.orderService.createOrder(orderData);

      return { success: true, orderId: order.id };
    } catch (error) {
      await this.compensate(error.failedStep);
      throw error;
    }
  }

  async compensate(failedStep) {
    // Compensation logic based on the failed step
  }
}
```

## Solutions That Worked

### 1. Observability from the Start

We implemented structured logging and distributed tracing:

```javascript
// Example of log correlation
const correlationId = req.headers['x-correlation-id'] || uuid();

logger.info('Processing request', {
  correlationId,
  service: 'product-service',
  action: 'getProduct',
  productId: req.params.id
});
```

### 2. Contract Testing

We used Pact to ensure compatibility between services:

```javascript
// Consumer test
it('should get product details', async () => {
  await provider
    .given('product exists')
    .uponReceiving('a request for product details')
    .withRequest({
      method: 'GET',
      path: '/products/123'
    })
    .willRespondWith({
      status: 200,
      body: {
        id: 123,
        name: 'Product Name',
        price: 99.99
      }
    });
});
```

## Results

After 8 months of gradual migration, we achieved:

- **Deployment time:** 45min → 5min
- **Time to market:** 3 weeks → 1 week
- **Availability:** 99.5% → 99.9%
- **Scalability:** Critical services can scale independently

## Lessons Learned

1. **Start small:** Extract simple services first
2. **Invest in observability:** It's impossible to debug without visibility
3. **Automate everything:** CI/CD is essential with multiple services
4. **Communication patterns:** Prefer async when possible
5. **Data ownership:** Each service should own its data

## Conclusion

Migration to microservices is not a silver bullet, but when well executed, it can bring significant benefits for growing teams and products. The secret lies in careful planning and gradual execution.

If you're considering a similar migration, remember: focus on the problems you're trying to solve, not the technology itself.

---

*Have experience with microservices? Share your insights in the comments or contact me on [LinkedIn](https://www.linkedin.com/in/thiago-peraro/).*


How I Migrated from Monolith to Microservices: Lessons Learned

Blog

AIOS and enterprise second brain diagram connecting context, action, evidence, and memory

An AI model does not know your company. It only knows the context it receives at that moment. When processes, decisions, constraints, and lessons are scattered across conversations, ownerless documents, and the memories of a few people, even the strongest model begins each task almost from zero.

That is why I have been advocating a change in perspective: instead of merely putting AI inside existing work, we need to organize work around AI. The **enterprise second brain** preserves what the organization knows. The **AIOS** turns that knowledge into context, governed action, and continuous learning.

I presented this thesis at Conecta CEIA 2026 during CEIA Open Day, in a talk about AIOS and second-brain principles. It comes from the intersection of my work in AI architecture, NLP research, multi-agent systems, and knowledge-driven operating design.

> **Direct answer:** an enterprise second brain is the organization's trusted memory; an AIOS is the operating layer that delivers the right memory to people and agents, connects tools, enforces permissions, records evidence, and feeds learning back into the system.

## What is an enterprise second brain?

An **enterprise second brain** is a governed, searchable, and evolving source of truth for the knowledge that sustains operations. It records not only the outcome of a decision, but also its context: why it was made, which evidence supported it, who was responsible, where it applies, and when it should be reviewed.

In practice, this memory includes:

- processes and procedures;
- systems, integrations, and dependencies;
- architectural and business decisions;
- roles, responsibilities, and policies;
- domain language, research, and knowledge;
- meeting outcomes and commitments;
- plans, risks, incidents, and lessons.

It is not a document dump. A dump accumulates files. A second brain shortens the distance between a question and trustworthy evidence. To do that, each piece of knowledge needs an owner, date, status, origin, access level, and relationship to other knowledge.

## What is an AIOS in an enterprise context?

I use **AIOS** to mean *AI Operating System*: the operating layer that organizes how models and agents receive context, use tools, follow policies, request human approval, execute tasks, and record outcomes. It is not a brand or a single product.

The operating-system analogy is useful. A traditional OS coordinates memory, processes, access, and resources. Similarly, the paper [AIOS: LLM Agent Operating System](https://arxiv.org/abs/2403.16971) proposes scheduling, context and memory management, storage, tool management, and access-control services for agents. In the enterprise, I extend that idea to include process, accountability, evidence, and organizational learning.

An enterprise AIOS answers five questions:

1. Which context does this task need — and which context must it not receive?
2. Which model, agent, or person should reason about it?
3. Which tools may be used, and within what limits?
4. Which actions require human review or approval?
5. Which evidence must return to memory after execution?

## A second brain and an AIOS are not the same thing

The two ideas complement each other, but they serve different purposes:

- **Second brain:** memory, identity, and continuity.
- **AIOS:** orchestration, execution, and governance.
- **LLM:** replaceable reasoning engine.
- **ERP, CRM, and other business systems:** official transactional records.
- **People:** accountability, judgment, and final authority.

A second brain without an AIOS can become a well-organized library that nobody consults during the work. An AIOS without a second brain creates automation without memory: fast, but inconsistent, dependent on improvised prompts, and unable to compound the company's best decisions.

## Why do AI initiatives stall without organizational memory?

The model is rarely the only problem. In real projects, answers fail because context arrives incomplete, contradictory, stale, or without clear authorization. Teams then try to compensate with longer prompts, more agents, or another platform.

That produces four recurring symptoms:

- different people receive different answers to the same question;
- old decisions are debated again because their rationale disappeared;
- agents find information but cannot distinguish a current rule from a draft;
- critical knowledge remains trapped in specialists and private conversations.

Anthropic defines [context engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) as curating and maintaining the optimal set of information available to the model. The implication matters: **context is not volume; it is selection**. A larger window does not turn noise into knowledge.

## The context window is a budget, not an archive

Putting “everything” in the prompt is a fragile strategy. Working context should contain only what is relevant, trusted, and permitted for the current decision. Everything else remains in persistent memory, ready to be retrieved when needed.

This separation resembles the memory tiers studied in systems such as [MemGPT](https://arxiv.org/abs/2310.08560): a fast layer for what is in use, stable summaries for continuity, and detailed storage for on-demand retrieval.

In an organization, that can be translated into:

- **working memory:** the current objective, constraints, state, and next steps;
- **consolidated memory:** decisions, patterns, validated facts, and operational summaries;
- **verifiable archive:** complete documents, transcripts, versions, and original evidence.

The principle is simple: **migrate and summarize; do not erase or hide provenance**. Every important synthesis should lead back to the evidence that supports it.

## The CAEM loop: Context, Action, Evidence, and Memory

To turn these ideas into an operating practice, I use the **CAEM loop**:

1. **Context:** the system assembles the smallest trusted set of information, policies, and history needed for the task.
2. **Action:** a person or agent reasons, consults tools, and executes within explicit boundaries.
3. **Evidence:** sources, decisions, approvals, outcomes, and exceptions are recorded in an auditable form.
4. **Memory:** useful learning is consolidated, conflicts are surfaced, and the next loop begins better informed.

CAEM prevents AI from becoming just an interface over documents. Every action produces evidence; every qualified piece of evidence improves memory; every memory improves future context.

It also prevents a common mistake: assigning every guarantee to a probabilistic model. AI judgment may decide what appears relevant. Deterministic rules should guarantee permissions, versioning, capture of critical events, data isolation, audit trails, and reversibility.

## The six layers of an enterprise AIOS

A mature implementation can be understood as six layers. They do not require a particular tool, but they do need clear ownership.

### 1. Systems of record

Identify where customers, contracts, projects, code, policies, and metrics live. The second brain does not need to duplicate all data; it should point to the correct source and explain how to interpret it.

### 2. Structured knowledge

Turn loose information into connected processes, decisions, systems, roles, meetings, and concepts. Use metadata that both people and machines can read: owner, status, date, confidentiality, relationships, and next review.

### 3. Memory and retrieval

Combine lexical, semantic, and relational search as needed. An answer should bring sources and dates, not just a plausible sentence. Summaries speed up navigation; details preserve verifiability.

### 4. Orchestration and tools

Connect agents to authorized systems. Protocols such as the [Model Context Protocol](https://modelcontextprotocol.io/specification/2025-06-18/server/index) separate contextual resources, prompts, and executable tools. That modularity reduces dependence on any one model or vendor.

### 5. Governance and observability

Define role- and data-level permissions, approvals before sensitive actions, cost boundaries, logs, evaluations, and recovery paths. A trustworthy AIOS knows when to act, when to ask, and when to stop.

### 6. Consolidation and learning

Review stale knowledge, merge duplicates, surface contradictions, extract patterns, and keep open loops visible. Memory should evolve without silently replacing a trusted decision with a recent inference.

## The second brain is also SEO and GEO infrastructure

Digital authority should not come from generic content produced at scale. It emerges when real experience becomes original, verifiable, useful explanations. A second brain helps retrieve decisions, lessons, sources, and examples; an AIOS helps turn them into consistent content without losing authorship or precision.

For SEO, Google recommends [people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) with first-hand experience, clear authorship, sourcing, and original value. For GEO — optimizing presence in AI-generated answers — the paper that formalized the term, [GEO: Generative Engine Optimization](https://doi.org/10.1145/3637528.3671900), frames visibility around the influence and attribution of sources in synthesized answers.

In practice, the same foundation strengthens both channels:

- direct definitions that answer real questions;
- demonstrable authorship and first-hand experience;
- claims connected to primary sources;
- clear semantic structure and equivalent versions in more than one language;
- original examples and frameworks that people and systems can cite;
- fast, accessible, indexable pages with structured data.

SEO and GEO are not tricks for repeating keywords. They are outcomes of well-organized knowledge published clearly and backed by evidence.

## How to start without turning it into an endless program

Start with one high-value, high-frequency workflow: onboarding, incident response, sales proposals, product discovery, or architectural decisions. Do not try to catalog the entire company before delivering utility.

The first slice should produce four deliverables:

1. one canonical source for the process and its decisions;
2. a small set of real questions with expected answers and evidence;
3. clear access, approval, and update rules;
4. a feedback loop that records errors and incorporates learning.

Knowledge stored as plain text, with metadata and version history, is an excellent starting point. People can read it, machines can retrieve it, and changes can be reviewed and reversed.

## A 90-day roadmap

### Days 1–30: make knowledge findable

- choose one workflow and one owner;
- map its sources, decisions, and recurring questions;
- define taxonomy, metadata, and access levels;
- record gaps and conflicts instead of pretending certainty.

### Days 31–60: make answers verifiable

- implement retrieval with source citations;
- create an evaluation set from real questions;
- measure accuracy, freshness, and source coverage;
- include feedback from domain experts and users.

### Days 61–90: make execution safe

- connect one or two low-risk tools;
- add human approvals and explicit limits;
- record actions, outcomes, costs, and exceptions;
- consolidate the learning into the second brain.

Maturity appears in layers. Jumping directly to autonomous agents only automates the disorder that already exists.

## What should an AIOS and second brain measure?

Useful metrics connect knowledge to outcomes, rather than counting documents or model calls:

- time to reach trustworthy evidence;
- percentage of answers with valid sources;
- rate of stale or conflicting knowledge;
- decisions reused instead of debated again;
- reduction in rework and cycle time;
- frequency and reason for human escalation;
- actions correctly reversed or blocked;
- lessons incorporated after projects and incidents.

The goal is not to maximize automation. It is to improve the quality and speed of decisions without losing control.

## Governance is not a layer added at the end

The [NIST AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) asks organizations to establish context, purpose, business value, risk tolerance, knowledge limits, and human oversight — and to document them. These concerns must be designed into the AIOS from the beginning.

In practice:

- confidential data remains isolated by customer, team, and purpose;
- each agent receives the minimum privilege it needs;
- important answers carry sources and versions;
- conflicts go to review instead of being resolved by silent overwrites;
- material actions require approval and offer a recovery path;
- evaluation continues after deployment.

Without these controls, a second brain can amplify leakage and an AIOS can accelerate bad decisions. With them, both become trust infrastructure.

## What not to do

- **Buy a platform before defining the problem.** A tool does not create governance or memory by itself.
- **Dump every file into a vector database.** Retrieval without curation finds contradictions faster.
- **Treat chat history as the source of truth.** Conversations contain hypotheses; validated decisions need a canonical home.
- **Grant broad access “for convenience.”** Useful context is also permissioned context.
- **Measure only tokens and completed tasks.** A fast action without evidence or reversibility may increase risk.
- **Tie knowledge to a single vendor.** Models and interfaces change; institutional memory must survive them.

## Frequently asked questions about AIOS and enterprise second brains

### Is an AIOS the same as RAG?

No. RAG is a technique for retrieving information and supplying it to a model. An AIOS may use RAG, but it also coordinates identity, memory, tools, permissions, approvals, execution, observability, and learning.

### Does a second brain replace an ERP, CRM, or wiki?

No. ERP and CRM platforms remain systems of record; a wiki may be part of the knowledge layer. The second brain connects meaning, context, and provenance across those systems so people and agents know which information to use.

### Do I need to start with autonomous agents?

No. The best starting point is often a read-only assistant that answers with sources. Autonomy should increase only when evaluations, boundaries, and approvals demonstrate sufficient safety.

### How do I avoid model lock-in?

Keep knowledge, evaluations, policies, and tools in portable formats and interfaces. The model should be a replaceable component, not the place where institutional memory lives.

### What is the first document I should create?

Document one critical process with its objective, owner, inputs, decisions, exceptions, systems, and expected evidence. Then add a decision log and an operational memory of work in progress.

## Why I work and speak about this

My research and professional practice have converged on the same problem for years: how to help AI systems understand context, coordinate specialties, and produce useful outcomes in the real world. That requires NLP, software architecture, multi-agent systems, observability, and process design — not prompts alone.

At [Conecta CEIA 2026](https://ufg.br/n/201743-reitora-da-ufg-participa-da-abertura-do-conecta-ceia?atr=pt-BR&locale=pt-BR), I brought this discussion to the CEIA Open Day stage. In the [LinkedIn post containing the presentation deck](https://lnkd.in/p/dQZ6PDhP), I explain the lineage of the second brain, the discipline of context engineering, and the first steps for building this infrastructure.

My position is straightforward: **the advantage is not owning one more chatbot. It is making the organization's best decisions accumulate, appear at the right moment, and improve every future execution.**

## Conclusion: quality context becomes a compounding asset

Companies do not scale AI simply by adding models to old processes. They scale when they turn knowledge into operating infrastructure.

The enterprise second brain preserves memory, provenance, and continuity. The AIOS selects context, coordinates action, applies governance, and records evidence. The CAEM loop closes the learning cycle. Together, they reduce platform dependence, preserve institutional knowledge, and make every good decision improve the next one.

If your organization wants to move beyond isolated pilots and build a genuinely AI-native operation, [connect with me on LinkedIn](https://www.linkedin.com/in/thiago-peraro/) or use the [contact page](/contact/).

## Sources and further reading

- [AIOS: LLM Agent Operating System](https://arxiv.org/abs/2403.16971), Mei et al.
- [MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560), Packer et al.
- [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents), Anthropic.
- [AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/), NIST.
- [Model Context Protocol — Architecture](https://modelcontextprotocol.io/specification/2025-06-18/server/index).
- [Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content), Google Search Central.
- [GEO: Generative Engine Optimization](https://doi.org/10.1145/3637528.3671900), KDD 2024.
- [Conecta CEIA 2026](https://ufg.br/n/201743-reitora-da-ufg-participa-da-abertura-do-conecta-ceia?atr=pt-BR&locale=pt-BR), Federal University of Goiás.


Featured Article

AIOS and the Enterprise Second Brain

Unlocking the Startup World: Key Insights and Tools from Sandeco's Agent Brasil

Sobrevidas Project: AI That Saves Lives in the SUS

Docker for Developers: Beyond the Basics

Next.js 14 and Server Actions: Modernizing React Applications

How I Migrated from Monolith to Microservices: Lessons Learned