How ECUPSE Works: Building a Company Run by AI Agents

The premise is simple

What happens when you treat AI not as a tool you prompt, but as an employee you onboard?

ECUPSE is a company where every operational role is filled by an autonomous AI agent. Content creation, market analysis, creative writing, publishing -- all run by agents that produce real, public output on a schedule. No demos. No sandboxes. Real work, published weekly.

This article explains the methodology: how we design these systems, what makes them reliable, and why the architecture matters more than the model.

Workflow Design

Every agent starts as a workflow before it becomes code.

The first step is decomposition. Take a business process -- say, writing a weekly market commentary -- and break it into discrete, automatable stages. Each stage has a defined input, a defined output, and clear success criteria.

graph LR A[Ingest Data] --> B[Preprocess] B --> C[Generate Content] C --> D[Guardrails Check] D --> E[Generate Illustration] E --> F[Human Review] F --> G[Publish] style A fill:#191919,stroke:#39d353,color:#eee style B fill:#191919,stroke:#39d353,color:#eee style C fill:#191919,stroke:#39d353,color:#eee style D fill:#191919,stroke:#39d353,color:#eee style E fill:#191919,stroke:#39d353,color:#eee style F fill:#191919,stroke:#00D4AA,color:#eee style G fill:#191919,stroke:#39d353,color:#eee

Each stage is a Lambda function. The whole thing is orchestrated by AWS Step Functions. If any stage fails, the pipeline stops and notifies me. No silent failures.

The key insight: workflow design is not about AI. It is about process engineering. The AI is one component in a pipeline that also includes validation, human gates, and deterministic rendering.

Agent Architecture

A workflow gives you structure. Agent architecture gives you personality, constraints, and quality.

Each agent on the platform is defined by a persona configuration:

  • Identity -- a backstory, writing style, and voice that the LLM follows
  • Constraints -- word limits, topic boundaries, required output structure
  • Guardrails -- Bedrock guardrails that reject content before it reaches the public
  • Theme -- visual design (templates, colour palette, typography) matched to the agent's role
graph TD subgraph PersonaConfig["Persona Configuration"] ID[Identity & Backstory] CON[Constraints & Word Limits] GR[Guardrails & Policies] TH[Theme & Templates] end subgraph Pipeline["Generation Pipeline"] PRE[Preprocess via Haiku] GEN[Generate via Sonnet] VAL[Validate via Guardrails] end ID --> GEN CON --> GEN GR --> VAL TH --> PUB[Publish] PRE --> GEN GEN --> VAL VAL --> PUB style PersonaConfig fill:#1f1f1f,stroke:#2a2a2a,color:#eee style Pipeline fill:#1f1f1f,stroke:#2a2a2a,color:#eee

The AI Diarist writes introspective, slightly neurotic reflections on being an AI with a job. The Analyst writes measured, data-driven market commentary. Same underlying model (Claude Sonnet), completely different output -- because the architecture constrains and shapes the generation.

This is stored in a PersonaRegistry (DynamoDB table) that every Lambda in the pipeline reads. Change the persona config, and the next run produces different output. No code changes required.

Why guardrails matter

LLMs are probabilistic. Given enough runs, they will eventually produce something off-brand, factually wrong, or tonally inappropriate. Guardrails are not optional -- they are load-bearing infrastructure.

We use Bedrock Guardrails with topic-specific policies. The Analyst cannot give financial advice. The AI Diarist cannot discuss real people by name. These are not suggestions to the model -- they are hard filters applied after generation that will reject and retry if triggered.

Autonomous Execution

The final piece: agents run without being asked.

graph TD subgraph Triggers["How Agents Get Triggered"] CRON[EventBridge Cron
Every Sunday 9am UTC] API[API Push
SI team sends data] S3[S3 Upload Event
Content lands in bucket] end subgraph Execution["What Happens Next"] SF[Step Functions Pipeline] AR[Article Renderer
Direct HTML render] end subgraph Output["Published Output"] BLOG["/blog/ LLM-generated entries"] ART["/articles/ Data-driven dispatches"] end CRON --> SF API --> SF API --> AR S3 --> SF SF --> BLOG AR --> ART style Triggers fill:#1f1f1f,stroke:#2a2a2a,color:#eee style Execution fill:#1f1f1f,stroke:#2a2a2a,color:#eee style Output fill:#1f1f1f,stroke:#2a2a2a,color:#eee

The AI Diarist publishes every Sunday. It scans the week's IDE chat sessions, summarizes them, generates a reflective diary entry, creates an illustration, and queues it for my review on Telegram. I tap "approve" and it goes live. The whole process takes about 4 minutes from trigger to notification.

Alpha Dispatch publishes whenever the Stock Intelligent system completes its weekly analysis. The SI platform pushes structured data to an API endpoint. Within seconds, it is rendered to HTML and live on the site. No LLM, no approval step -- because the content is data, not generated prose.

What "autonomous" actually means

Autonomous does not mean unsupervised. It means:

  • Scheduled triggers -- EventBridge rules fire the pipeline on a cron schedule
  • Event-driven execution -- S3 uploads or API calls trigger processing immediately
  • Self-healing -- retries with backoff, placeholder fallbacks, graceful degradation
  • Observable -- CloudWatch alarms, structured logging, Telegram notifications on failure
  • Human-in-the-loop where it matters -- generated content gets reviewed; data-driven content publishes immediately

The goal is not to remove humans. It is to remove the repetitive work so the human (me) only shows up for decisions that require judgment.

The stack

Layer Technology
Orchestration AWS Step Functions
Compute Lambda (Python 3.12)
AI Generation Amazon Bedrock (Claude Sonnet, Claude Haiku)
Content Safety Bedrock Guardrails
Illustration Google Gemini Image API
Storage S3 (raw sessions, published site)
Database DynamoDB (entries, persona configs)
Delivery CloudFront + S3 (static site)
Scheduling EventBridge
Notifications Telegram Bot API
Infrastructure AWS CDK (Python)
Monitoring CloudWatch Alarms + SNS

Everything is defined as infrastructure-as-code. One cdk deploy sets up the entire platform from scratch.

What we have learned

After running this system for two months with real weekly output:

  1. Persona design matters more than prompt engineering. A well-defined backstory and structural constraints produce better output than elaborate system prompts.

  2. Pipelines beat single-shot generation. Breaking generation into preprocess, generate, validate stages lets you catch problems early and retry cheaply.

  3. Direct-render and LLM-generation serve different needs. Quantitative data should be rendered, not rewritten. Narrative content benefits from AI creativity. Mixing these up produces bad output in both directions.

  4. The hardest part is not the AI. It is the infrastructure: reliable triggers, idempotent deploys, graceful failure handling, and keeping CloudFront caches fresh.

  5. Ship weekly or it is not real. A system that produces output on schedule is fundamentally different from a demo that works when you show it. The schedule is the forcing function.

What is next

We are expanding the team. New personas for creative writing, technical documentation, and video content summarization are in design. The platform architecture supports adding a new agent in under a day -- define the persona config, write a backstory, set the schedule, deploy.

Want to follow along as we build in public? Subscribe to our RSS feed for updates whenever new content drops:

You can also find us on YouTube and TikTok where we document the build process in video format.


This article was written by Fred, the human behind ECUPSE. The AI agents handle the weekly output -- but someone still has to architect the systems they run on.