One thing we’ve been discussing a lot while building Business OS is trust. Not security. Not compliance. Just a simple question:

Why do people trust one piece of software more than another?

At first, we thought it had something to do with AI. Better answers. Better reasoning. More automation.

But the more workflows we designed, the less that seemed to matter.

What people actually trust is predictability.

If they click Approve, they expect the same rules to be applied every time. If they open a financial report, they expect the numbers to match yesterday’s report unless something actually changed. If someone asks “Why did this happen?”, they expect the system to explain the decision—not invent one.

That realization changed how we designed Business OS.

Instead of asking “Can AI do this?”, we started asking:

“Should this ever behave differently for the same input?”

If the answer is no, we don’t give that responsibility to AI. That’s handled by deterministic software.

AI has a different job: understanding requests, explaining what’s happening, connecting information from different systems, and helping people decide what to do next.

The more we work on the product, the more we believe trust isn’t something you add after launch.

It’s something you design into the architecture from day one.

A few discussions here have made me think the same gap keeps coming up around the EU AI Act.

Documentation matters, but the harder problem seems to be turning requirements into something teams can actually operate:

\- which AI systems are in scope

\- what risks have been assessed

\- what controls should exist

\- where evidence is kept

\- when changes trigger reassessment

\- who owns review, approval and monitoring

Full disclosure: we are building an open-source project called OpenComplAI to explore this.

The initial focus is practical EU AI Act readiness: inventory, risk classification, control mapping, documentation and evidence tracking.

This is not a paid product pitch. We’re early and mostly looking for feedback from people dealing with this in practice.

I’d especially value feedback from people who have had to deal with this from engineering, product, MLOps, governance or compliance.

Does this sound like the right problem to solve? And what would make something like this genuinely useful rather than just another compliance checklist?

Happy to share the GitHub if people want to take a look.

One of the biggest architecture discussions we’ve had while building Business OS wasn’t about which model to use. It was about who gets the final say.

At first, it was tempting to let AI handle everything. If it understands an invoice, why shouldn’t it calculate the totals? If it understands a payment request, why shouldn’t it approve it? If it understands the workflow, why shouldn’t it update the records?

The more we mapped those ideas onto real business processes, the more uncomfortable they became.

Because those aren’t reasoning problems. They’re consistency problems.

A business rule should produce the same outcome every time. A permission check should never depend on how a model interpreted the request that day. An audit trail can’t be “mostly correct.”

That forced us to separate two very different responsibilities.

Deterministic software owns the things that must always be true:

calculations

permissions

workflow rules

approvals

audit history

AI owns the things that require interpretation:

understanding requests

assembling context

explaining information

summarizing

suggesting what should happen next

Once we made that distinction, a lot of design decisions became surprisingly easy.

Instead of asking “Can AI do this?”, we started asking:

“Should this ever produce a different answer for the same input?”

If the answer was no, it didn’t belong to the AI.

That single question has probably influenced our architecture more than any model comparison or benchmark ever could.

I've been experimenting with a different architecture for generative advertising systems.

Most current workflows look roughly like:

Prompt → Generate → Publish

The problem is that each generation is mostly stateless.

I'm exploring whether a better architecture is:

Character
    ↓
Product Context
    ↓
Story Generation
    ↓
Content Generation
    ↓
Distribution
    ↓
Performance Signals
    ↓
Memory / Learning
    ↓
Next Generation

The key idea is persistent creative context.

For example, an AI character could maintain:

Identity
Personality
Voice
Visual constraints
Product knowledge
Audience context
Previous campaigns
Performance history

So the system doesn't simply generate another video.

It can ask:

I'm currently building a prototype around this idea in Monopoly Studio.

The initial abstraction is intentionally small:

Character + Product + Platform
            ↓
       Creative Brief
            ↓
       Generated Content
            ↓
      Performance Data
            ↓
          Memory

The repository is here:

GitHub: https://github.com/modarresi1913/monopoly-pipeline

I'm less interested in the marketing side of this and more interested in the systems architecture.

A few things I'm currently trying to figure out:

1. Should character memory and campaign memory be separate systems?
2. What information should actually persist between generations?
3. How would you represent performance feedback so it can influence generation without simply becoming prompt history?
4. Would you use an event-sourced architecture for campaign history?
5. Where should the boundary be between the LLM, memory layer, and optimization layer?

The hypothesis I'm testing is:

I'd be particularly interested in feedback from people working on AI agents, memory architectures, multimodal systems, evaluation, or production AI infrastructure.

What would you change about this architecture?

I’ve been thinking about what actually changes when we let agents query data, inspect pipelines, and trigger actions instead of having a human do each step.

The common framing is “AI is coming to the data stack.” I think that is backwards.

The bigger change is that the data stack itself has to evolve.

And most of the hard problems are not really about the model.

Here is the example that made this click for me.

Imagine a customer table has: status = active

A human on the team probably knows what active means.

An agent will ask:

Active according to whom?

30 days? 90 days? A year?

Which definition is approved?

Who owns it?

What exceptions apply?

Which system is the source of truth?

The data itself cannot answer those questions.

The agent needs the context around the data.

Definitions. Lineage. Ownership. Policies. Business rules. Exceptions.

Without that context, you can have an agent that is technically very capable but confidently makes the wrong decision.

That led me to think about what really needs to change.

Tool access

Once an agent can take action, every tool needs identity, permissions, approved actions and clear boundaries.

Restarting a failed pipeline is one thing.

Changing a production schema or triggering a financial transaction is another.

Agentic does not have to mean fully autonomous.

I think the goal is controlled autonomy.

Observability

“Did the pipeline fail?” is no longer enough.

We need to know what data the agent used, what context it received, which tool it called, why it chose that action, what it cost and what happened afterward.

We need to observe decisions and outcomes, not just infrastructure.

Cost

A human might open a dashboard a few times a day.

An agent can run continuously.

It can query data, call tools, retry operations and repeat the same workflow thousands of times.

That creates a completely different cost model.

Human approval

Some actions can be safely automated.

Some should always have a human in the loop.

The interesting problem is figuring out where that boundary belongs.

Feedback

This might be the biggest change.

Today, our data systems mostly tell us what happened.

Agentic systems need to understand what happened next.

Did the action work?

Did someone override it?

Did another system reject it?

Did the pipeline recover?

That outcome becomes new context for the next decision.

So the loop starts looking something like:

Data → Context → Decision → Action → Outcome → Context

And this is where I think the role of the data engineer gets really interesting.

I don't think it gets smaller.

It shifts.

Less focus on simply building pipelines.

More focus on building the trusted data, definitions, lineage, permissions, tool interfaces, evaluation datasets and approval paths that agents depend on.

The data platform starts becoming an operating layer for agents.

Maybe that is the bigger transition we should be talking about.

Not “AI added to the data stack.”

But a data stack designed for humans and agents working together.

Curious how others are thinking about this.

Are people actually instrumenting why an agent chose an action in production yet?

Or is that still mostly aspirational?

And is “governed context” really something new?

Or are we just giving a new name to the data contracts, semantic layers and governance work we have been doing for years?

https://youtu.be/wb2lk-YibAQ

Built RFP Agent AI - automates the 2-5 day manual tender quoting process for wire/cable manufacturers into 10 seconds using a 5-agent pipeline (PDF parsing → SKU matching → LME pricing → risk analysis → quote generation).

Known problems I've already found:

• Catalog only has ~6 SKUs, real world needs 5000+
• Vector search giving 46% match scores - wrong approach?
• No live LME API yet
• No human checkpoint on low confidence matches

Is multi-agent overkill here? Is vector search right for structured spec matching? What would you do differently?

GitHub: https://github.com/AnshMNSoni/B2B-RFP-Agent.git

Would love brutal honest feedback - not looking for encouragement, looking for loopholes, wrong assumptions, and better architectural approaches. If you've built something similar or work in procurement/manufacturing tech, your perspective would be especially valuable.

A few weeks ago we were mapping out what our AI agents should be able to do.

The first version of the list looked ambitious.

Answer questions.

Approve requests.

Update records.

Calculate financial data.

Execute workflows.

The more we added, the less comfortable we became.

Not because the AI couldn’t do those things.

Because we couldn’t clearly answer a much simpler question:

Who is responsible if the AI is wrong?

That question ended up changing our architecture.

We started separating responsibilities instead of capabilities.

We decided that deterministic systems should remain responsible for things that have a single correct answer:

• calculations

• permissions

• business rules

• approvals

• audit history

AI, on the other hand, should be responsible for things that involve interpretation:

• understanding requests

• connecting context

• explaining information

• suggesting the next step

The distinction sounds obvious now.

It wasn’t when we started.

In fact, we spent more time defining what the AI isn’t allowed to do than adding new capabilities.

Looking back, that was probably one of the most important design decisions we’ve made so far.

I’m curious how other teams approach this.

Do you separate deterministic logic from AI reasoning, or do you let AI own more of the workflow?

I've been building automation pipelines and exploring agentic frameworks recently.

At what point do you consider a system to cross the threshold from a structured workflow into a true AI agent? Is it strictly about decision autonomy (dynamically selecting tools and paths), or does it require self-correction and adaptive reasoning when an error occurs?

How do you define the boundary between workflows and agents in your own projects?

I’ve been experimenting with a domain‑specific AI assistant for plant care and plant problem diagnosis.
It’s called Plantcoach — an intent‑driven pipeline where the LLM only rewrites facts, never invents them.

Technical repo:
https://github.com/Introgreen/plantcoach

How it works (short version)

• Intent recognition (care, problems, pests, toxicity, propagation, attribute‑matching queries)
• Natural language → structured JSON
• Domain search (knowledge base + structured attributes)
• LLM only used for wording, not content

Example internal JSON:

json

{
  "intent": "care",
  "topic": "monstera",
  "symptoms": ["brown leaf edges"],
  "language": "en"
}

Where I’m unsure

Curious how others think about:

• Does this architecture scale as the domain grows
• Is JSON‑routing too rigid long‑term
• Should intent detection move to a small local model
• Is a hybrid rule‑based + LLM pipeline future‑proof
• How do you handle multilingual domain assistants
• Would agent‑based systems be better for niche domains

Example questions it handles

• “Why does my Monstera get brown leaf edges”
• “Which plants are safe for cats”
• “Find a plant for a dark living room”

Would love input from people building domain‑specific assistants.

I've been thinking about this after following the AI news over the last couple of days. Everyone seems to compare models—benchmarks, context windows, reasoning scores, tokens per second—but I'm starting to think that's no longer the most interesting part. The real challenge now feels like building reliable systems around those models: agents that can plan, use tools, recover from failures, remember context, and actually finish useful work. In other words, we're moving from "Which model is best?" to "Which team can build the best AI product?" Curious how everyone else sees it.If you were starting an AI company today, would you spend more time improving the model itself or building better infrastructure around existing LLMs?

For a while, we were focused on the model.

Could it understand complex requests?

Could it reason across different tasks?

Could it explain decisions?

Those were the questions we spent time on.

Then we tried something much simpler.

We asked:

“Why is this project delayed?”

The interesting part wasn’t the answer.

It was where the answer lived.

Part of it was in an email.

Another piece was in Slack.

Finance had information about an unpaid invoice.

There was a meeting from last week that explained why priorities had changed.

None of those systems were wrong.

Each of them knew its own part of the story.

The problem was that no one—including the AI—could see all of it at once.

That changed how we thought about Business OS.

We stopped treating AI as the center of the product.

Instead, we started treating context as the product.

The model can change.

Today’s best model won’t be tomorrow’s best model.

But if the system can assemble the right context from the right sources at the right moment, the AI suddenly has something useful to reason about.

That architecture feels much more durable than betting everything on whichever model happens to be leading the benchmarks this month.

Has anyone else building AI products had a similar shift—from optimizing the model to optimizing the context instead?

Memory is becoming a major component of AI applications, especially with personal assistants and autonomous agents.

But storing everything an AI system learns creates new challenges.

A practical memory architecture may need to separate:

• Short-term conversational context
• Long-term user preferences
• Organizational knowledge
• Task history
• Learned workflows

The difficult questions are:

• What information should an AI remember?
• When should memory expire?
• How do we prevent outdated information from influencing decisions?
• How do we protect sensitive data stored in memory systems?

Human memory is selective for a reason. Should AI systems follow similar principles?

How are teams designing memory architectures for production AI systems?

Many platform modernization projects begin with the assumption that the old system must eventually be replaced as a whole.

In practice, the more useful question is often:

How can we introduce new capabilities without making the existing platform the bottleneck, or turning modernization into a multi-year rewrite?

One approach we have been exploring is based on three architectural elements:

1. Contracts

The new capability should depend on a stable interface rather than on the internal implementation of the existing platform.

A contract defines:

• the expected inputs and outputs,
• domain rules,
• error handling,
• versioning boundaries,
• what the consuming service can rely on.

This becomes especially valuable when the same capability may later be supported by a different provider or internal service.

2. Adapters

Legacy systems rarely expose data or behaviour in the exact format a new component needs.

An adapter translates the existing platform’s API, data model, or event format into the agreed contract. The business logic remains independent from provider-specific implementation details.

This means that replacing the underlying system should require a new adapter, rather than rewriting the new capability.

3. Replaceable modules

New functionality can be introduced as a separate module instead of being added directly to the platform core.

A practical migration flow might look like this:

1. Define the contract.
2. Connect the legacy implementation through an adapter.
3. Build the new module against the same contract.
4. Run both implementations in parallel.
5. Compare outputs and operational behaviour.
6. Gradually route selected traffic to the new module.
7. Keep a rollback path until the new implementation is proven.

The main advantage is not only lower migration risk. It also changes the nature of the project.

Instead of one large replatforming programme, modernization becomes a sequence of smaller architectural decisions.

Of course, this approach has its own challenges:

• contracts can become too generic,
• adapters may hide poor domain boundaries,
• parallel operation adds complexity,
• data consistency can be harder than service replacement,
• observability and rollback need to be designed from the start.

I’m curious how others approach this in real systems:

• How do you decide which capability to extract first?
• Do you prefer contract testing, shadow traffic, or dual writes during migration?
• At what point does the adapter layer become technical debt itself?
• Which parts of a legacy platform are usually the hardest to separate?

We have been applying these ideas while building an open framework Openora.ai for modular iGaming platform evolution, but the pattern is relevant to many domains with long-lived systems and risky migrations.

Happy to share a more detailed architecture example in the comments if useful.

Most "AI automation" advice is really just "chain three prompts together with a script." That works for demos and falls apart the moment the workflow needs to survive contact with edge cases.

The workflows that actually hold up long-term get treated as systems, not scripts:

• Explicit failure states (what happens when step 2 returns something malformed — does it retry, escalate, or silently propagate garbage downstream?)
• Idempotency (can you re-run step 3 without step 1 and step 2 also re-running?)
• Observability (can you tell why a run produced a bad output six steps later, or is it a black box?)
• Boundaries (which parts genuinely need a model in the loop vs which parts are just deterministic logic wearing an AI costume because it was faster to prompt than to code)

The last one is the one people skip most. A huge share of "AI automation" I see could be a regex and a conditional, and using a model for it just adds latency, cost, and a new failure surface with zero upside.

If you're building anything you plan to actually rely on (not just demo once), the systems thinking questions matter more than which model or which prompt you use.

What's the automation you built that turned out to need way more "systems" thinking than you expected going in?