ideas – ublo

bogdan » A Few Tips on Architecture and Attention

08:58 pm on Sep 20, 2026 | read the article | tags: ideas, medium

I like thinking about software architectures. I guess you already knew that, if you checked around here lately. I like thinking about large distributed systems and how that can take form in practice: boxes connected with arrows, queues, databases, caches, workers, clusters, and all the nice things that eventually wake somebody up at 3 in the morning.

Almost every job I’ve had forced me to do infrastructure work. Sometimes because I was the only person around, sometimes because I was managing a team and tried to protect them from the operational mess, and lately just doing it under my official job title, MLOps. The problem never changes much: you have something that needs to work and not enough people, time, or patience to operate everything that could theoretically make it work.

There’s a difference between liking something and being good at it. I’ve made my share of bad architectural decisions. But, more importantly, I had to live with them. Now, after all these years, my idea of what makes a good system has changed. I care less than I used to about finding the «best» component, and much more about what happens after the choice is made. After the benchmarks are forgotten and somebody has to upgrade it, recover it, or debug it at 2:00 a.m.

Tip #1: Knowledge is part of the infrastructure!

One of the first large systems I operated was a very popular radio station website receiving hundreds of thousands of requests per minute. I chose Apache HTTP Server. There were plenty of reasons why that was a bad idea at that scale, but Apache had one massive advantage that didn’t appear in any benchmarks: I knew it very well (at least back then). I knew how it failed, where the config files lived, which knobs were dangerous, what the logs meant, and when something broke I already had a full mental list of stupid things to try.

The launch wasn’t without incidents, but most took minutes to resolve rather than hours because very little was surprising. Once things settled down, I evaluated alternatives and eventually replaced Apache with Nginx, which was the better solution. Apache was probably the better first decision. There is a difference.

We usually compare technology as if the people using it don’t exist: throughput, latency, features, cost, GitHub stars. But knowledge is part of the infrastructure too. A component that is worse on paper but whose failure modes you understand can easily be cheaper than a perfect component you don’t know how to recover.

This isn’t at all an excuse to stop learning. There is still a minimum technical bar a component has to pass. Yet after that threshold, I no longer ask only whether a component solves the problem. I ask how expensive it will be for us to understand it when it doesn’t.

Tip #2: Architecture Belongs to the Operator

If I’m working alone, using something I know inside-out has enormous value. In a team, using something only I know becomes a liability.

Let’s say I use a Mac and everybody else uses Linux. I can write beautiful automation around whatever BSD-flavoured utilities happen to be on my machine. It works great until I go on vacation. Maybe rewriting it in JavaScript adds a runtime where a shell script would have been enough, but if everybody on the team can understand and maintain it, JavaScript may actually be the simpler system.

Architecture doesn’t belong to the architect. It belongs to whoever has to maintain it after the architect gets bored, promoted, fired, or simply goes offline for a week.

A system with five dull components understood by ten people can be much safer than a system with three brilliant components understood by one. This doesn’t mean choosing the lowest common denominator forever, but novelty has a cost. Introduce a new language, database, deployment model, and orchestrator in the same project and you may have built a training program disguised as software architecture.

Tip #3: Choose Small Contracts over Large Features

Years ago I worked on the foundation for dozens of news websites. The obvious choices were systems like Joomla or Drupal, which could do almost everything. That was exactly the problem: they could do almost everything, and brought their own abstractions, plugin systems, conventions, and assumptions about how the rest of the application should work.

Instead, I picked a much smaller CMS. It couldn’t do much, but it had clean boundaries around what it did, which meant we could attach other systems for streaming, encoding, publishing, and whatever strange requirement appeared next. That small core eventually became the basis for more than 60 projects because it didn’t insist on owning the entire architecture.

There’s this temptation to choose the component that covers the largest possible surface of the future. It sounds responsible. Except next year’s problems have an annoying habit of being different from the ones we imagined (remember LLMs?), while we pay for all the hypothetical features today in configuration complexity, upgrade pain, and coupling.

No worries. I don’t hunt for simple implementations as PostgreSQL and Linux are anything but simple. I hunt for small contracts and small operational surfaces.

Tip #4: There’s always the (hidden) cost of Human Attention

Qdrant is a good recent example. There are vector databases with better performance for particular workloads and products with more features. What I like about Qdrant would make a data scientist less excited: I can run it locally without reproducing a small data center, clustering is understandable, snapshots are straightforward, and recovery doesn’t require learning five other systems first.

Every component creates work twice: once when you build the system, and then forever. Upgrades, monitoring, backups, security patches, incidents, onboarding, and there’s also that strange problem that shows up every time there’s a team-building and nobody remembers how to fix.

Automation belongs in the same calculation. A mediocre component with good operational automation can easily be cheaper than a better component that requires humans to recover it.

Compute is expensive because AWS sends you a bill every month, yet human attention is easier to miss because nobody sends a sanity invoice when three engineers spend two days diagnosing an unhappy cluster.

Human attention is part of the infrastructure cost. It just doesn’t appear on the same cloud invoice.

One of my former CEOs used to say that with money, anybody can solve any problem. I don’t think that’s quite true. With money, many capacity problems get solved, but constraints don’t disappear because you have a larger credit card. Sometimes throwing 10x the compute at a rare spike is exactly the right answer.

Money buys margin and time, but it doesn’t automatically buy understanding. Throwing 10x at the problem just because nobody understands why 1x stopped working is something else.

Tip #5: The harder it is to undo, the more time it deserves

I recently watched two teams tackle vector search. One spent months understanding the workload, testing locally, simulating production traffic, and identifying bottlenecks, so a year later their setup has scaled with no major incidents. The other mostly added compute when things became slow. Incidents started almost immediately and eventually affected the release of a new long-sought feature.

Engineers, me included, like product questions because they have concrete answers. Which vector database? Which queue? Which LLM gateway? The boring questions matter more. How much data is there? How often does it change? How bad is stale data? What happens during a ten-minute outage? What’s the actual p99 we need? Who gets called when it breaks?

There is rarely a best component for a category. More often, there is a component that behaves better under a particular collection of constraints.

The other question is how painful a wrong decision will be. My Apache choice was relatively easy to undo because the web server sat behind a clean boundary. Changing the way an entire company represents customer identity is something else.

Architectural effort should be spent in proportion to how difficult a decision is to reverse. Move quickly on reversible choices and do thorough analysis on the ones that will hurt later.

And now, the conclusion

Maybe the useful question is not «What is the best architecture?» but «What is the cheapest architecture we can understand, operate, and change while still satisfying the actual constraints?»

In distributed architectures, cheap doesn’t mean the smallest cloud bill. It means attention: how much of the system somebody has to keep in their head, how many specialists are required when something breaks, how many people can safely change it, and how much new knowledge is required before touching it.

For a large company, some of this can be purchased. There’s a database team, infrastructure, security, SRE, and somebody whose entire job is understanding one particularly angry Kafka cluster. For a team of five, there’s Bogdan. And Bogdan doesn’t feel like working today.

Once something is technically good enough, I increasingly optimize for a different set of things (here’s a nicer list-like set of tips):

Prefer things you understand, unless the unfamiliar thing buys you both lunch and dinner.
Keep contracts small, so changing your mind doesn’t require changing everything.
Automate the things that happen twice, because twice quickly becomes twenty times.
Spread the knowledge around, and worry about anyone who’s always too busy to write some docs.
Spend analysis on decisions that are painful to reverse, and yes, YOLO everything else.

The goal isn’t to design a perfect architecture from day one, but to build a system you can run safely today, while leaving enough room to change your mind tomorrow.

Because eventually, the most expensive architecture isn’t the one with the highest cloud bill. It’s the one you can no longer afford to understand.

bogdan » A minimum viable experimentation platform for AI agents

09:19 pm on Sep 12, 2026 | read the article | tags: ideas, medium

If you don’t already know, I’ve been toying lately with enterprise AI agents. Here’s the article A minimum viable platform for enterprise AI agents. So, it made me think about how I would decide whether a new version of an AI agent is actually better than the one already running in production.

During development, the process is usually manageable: keep a set of test cases, run both versions, inspect a few traces, ask another model to grade the results and decide whether the change looks promising enough to continue. This is far more difficult when the thing being evaluated is not just a prompt or a model call, but an entire system made of components that change independently and influence each other in ways that are not always obvious.

Imagine a customer-support agent built from:

agent runtime
memory and retrieval
system prompt
model
tools
guardrails
application logic

The retrieval strategy changes and task completion improves on the test set. Maybe the agent is better, yet it may also make more model calls, cost 20% more, behave differently on real users, or simply benefit from another component that changed during the same period. At that point the problem starts looking more like experimentation and less like model evaluation.

So here’s my attempt to design the smallest platform I would be comfortable using to answer a fairly simple question:

should version B replace version A?

There is obviously a scale assumption here: if there’s only one agent, twenty manually reviewed test cases and a few internal users, most of the platform is unnecessary. It starts becoming useful when several teams change models, prompts, memory, tools and agent implementations independently, experiments run continuously, and somebody eventually needs to make a production decision based on evidence that should remain understandable a few months later. Thus, a perfect fit for my enterprise AI agents platform scenario.

Defining what B actually is

The first problem is basic. Let’s assume an experiment says:

A = agent-v17
B = agent-v18

What exactly is agent-v18?

If the prompt changes during the experiment, the retrieval index is rebuilt and the model gateway changes its default model, the label itself tells me very little about what was actually evaluated. This applies especially to agents because the behavior seen at the end is the result of the entire pipeline, not of one isolated model invocation.

Hence, the immutable pipeline definition is the treatment being evaluated. Something like:

pipeline:
  name: support-agent
  version: 18

components:

  runtime:
    artifact: agent-runtime@sha256:...

  memory:
    artifact: memory-service@sha256:...
    configuration:
      strategy: hybrid
      top_k: 8

  model:
    route: support
    model: provider/model-x

  prompt:
    artifact: sha256:...

  tools:
    - artifact: customer-lookup@sha256:...
    - artifact: refund-tool@sha256:...

The exact artifact format is not particularly important. What matters is that an experimental variant can be reconstructed as a system configuration and that, months later, someone can answer what a user assigned to B was supposed to execute. This also keeps the experimentation platform independent of what is changing.

One experiment may compare:

model X vs model Y

another:

memory top_k=5 vs top_k=8

and another may compare two completely different agent implementations. From the point of view of the experiment, all of them are pipeline variants. Once an experiment starts, freeze those definitions. If the treatment changes, create a new experiment iteration rather than silently rewriting what B meant historically.

Assignment is not (another) production dependency

The next problem is deciding who gets A and who gets B. There is a tempting implementation in which every request asks a central experimentation service for its treatment (seen it!), but that also means that the experimentation platform becomes (a critical) part of the availability and latency budget of the application itself, which seems like a poor trade for something whose primary purpose is measurement.

The first version uses deterministic hashing. The experiment control plane publishes the current configuration to an SDK embedded in the application, while the actual decision happens locally, giving the platform a useful failure property: if the experiment service is unavailable, the platform temporarily loses the ability to start a new experiment or change an allocation, but the application is unaffected, with the SDK continuing to use its last valid configuration.

For the MVP, support a few useful randomization units:

request
user
session
workflow_instance

The last one exists mostly because agents do not necessarily share the lifetime of a web request. An agent may start a repository migration today, wait for an external approval and continue tomorrow. If the assignment is recalculated from tomorrow’s experiment configuration, the same workflow may start on one implementation and finish on another, which makes both operational behavior and analysis unnecessarily difficult.

The assignment therefore remains pinned:

workflow_instance = migration-8291
variant           = B
pipeline          = agent-v18

and is carried every time the workflow resumes.

Assignment is not exposure

There is another distinction that becomes important as soon as the treatment is a component somewhere inside an agent pipeline: being assigned to a treatment does not mean that treatment actually participated in the execution.

Suppose I am testing two memory implementations and a user is assigned to B: memory-v2, but the agent answers the request without performing a memory lookup. The assignment exists, but the component under test never had an opportunity to influence the outcome.

Let’s keep those as separate events:

ASSIGNMENT
user-18271 → B

EXPOSURE
memory-v2 retrieval started

This gives useful experiment-health information as well. Instead of seeing only the number of users randomized to each arm, I can also inspect:

assigned          10,428
exposed            8,912
exposure rate      85.46%

If A and B have unexpectedly different exposure rates, investigate that difference first. A related problem appears when the treatment that was assigned is not the one that eventually executes. Suppose B selects model Y, model Y fails (with 503) and the gateway falls back to X. The record will show:

assigned_variant = B
realized_model   = X
fallback_reason  = provider_unavailable

the execution stays in B.

This is the usual Intent-to-Treat, or ITT, principle: analyze the subject according to the treatment it was randomized to, even when the realized execution deviates from that treatment. In this example the fallback behavior is itself part of what users experience when they are assigned to B, and removing those requests after the fact would change the population based on something that happened after randomization.

Exposure and realized-treatment information are still valuable, but primarily as experiment-health and diagnostic signals unless the analysis explicitly defines something else.

Traces explain what happened

The experiment result tells me whether an outcome changed. It does not tell me why.

An agent execution may look like:

Use OpenTelemetry for this rather than inventing another tracing protocol. The experimentation layer only needs to attach a small amount of additional context:

experiment.id
experiment.version
experiment.variant
experiment.assignment_id

pipeline.id
pipeline.version

execution.purpose

Now, move from an aggregate result such as:

B has a lower task completion rate

to a much more useful question:

show failed B traces

and inspect whether the new pipeline retrieves worse context, retries tools, falls back to another model, enters loops, or simply takes longer paths through the same task.

The trace itself is not the experiment record though. A trace is very good at explaining how one execution unfolded, but experimental outcomes do not necessarily share its lifetime. A customer may interact with an agent today and renew a subscription a week later, at which point the original trace has long finished.

So keep a smaller experiment event stream alongside tracing:

assignment
exposure
outcome
feedback
evaluation

The trace records execution. The event stream provides the bookkeeping needed to connect randomization to outcomes that may arrive later.

Offline evaluation uses the same pipeline

Before putting B in front of production users, test it against known scenarios. For agents specifically, a scenario shouldn’t be reduced to:

prompt
expected answer

because the interesting result may not be the text returned by the model at all. It may be what happened to the environment. A customer-support scenario could look like:

scenario:
  id: duplicate-charge-001

input:
  message: >
    I was charged twice for order 9811.

environment:
  fixture: duplicate-charge-customer

expected:
  refund_count: 1
  ticket_status: resolved

limits:
  max_turns: 15
  max_tool_calls: 20
  max_cost: 0.50

Then run the same scenario for both pipeline A and pipeline B, possibly several times, because agent executions are stochastic and two runs of the same configuration may follow different trajectories even when they start from equivalent state. The MVP uses a resettable sandbox containing fixture-backed services or test databases. Don’t try to build general multi-turn trace replay yet.

Replay works while the new candidate asks for interactions that were already recorded. If candidate B takes a different decision on turn three and calls a tool that the original trajectory never called, there is no recorded world in which that branch exists.

At that point the useful result is:

REPLAY_DIVERGED

rather than inventing a mock response and pretending the execution is still a replay.

A stateful sandbox lets both agents branch naturally while keeping their starting conditions controlled, which seems like a better first approximation of how agent evaluation should work.

Shadow execution bridges the gap between offline and production

There is one useful step between a controlled sandbox and exposing users to B: run B asynchronously against a copy of real production inputs without serving its output.

Variant B executes on realistic traffic, while writes and external side effects are either disabled or redirected to an isolated environment.

This provides production-like inputs and allows observation of:

latency
cost
tool usage
model fallbacks
guardrail failures
judge scores
trajectory differences

before the treatment reaches users.

Shadow execution still doesn’t tell me whether B improves the outcome I ultimately care about, because users never experience B and therefore cannot react to it. What it gives is an intermediate deployment step: realistic input distributions and runtime behavior without accepting the full product risk of a live experiment.

Not everything needs an LLM judge

Once the agent finishes a scenario, I still need to evaluate the result. That’s why the first version uses two kinds of evaluator.

The first is deterministic. If the task was to issue exactly one refund and resolve a ticket, inspect the environment:

refund_count == 1
ticket_status == resolved

There is little benefit in asking another model whether it thinks the agent probably completed a task when I can verify the resulting state directly.

The second evaluator is model-based. Some properties are difficult to express as assertions:

helpfulness
clarity
tone
quality of explanation

For those, an LLM judge comes in handy, but the judge becomes another versioned component rather than an anonymous source of truth:

evaluator
evaluator version
judge model
judge prompt
rubric

Every generated score keeps that provenance.

I also need to maintain a small human-labelled calibration dataset and periodically compare the judge against it. An LLM judge is a measurement instrument; if the instrument changes, I want to know whether its measurements have changed as well.

Agentic judges that browse, call tools or investigate additional evidence are useful and probably unavoidable for some domains, but they don’t have a place in the first version.

Oh! About the statistics

There is a lot of sophistication available in mature experimentation systems, but my go-to choice is to implement a small set of methods correctly rather than start with an impressive statistical menu that few users understand.

Here’s what the first version supports:

A/B allocation
binary metrics
continuous metrics
95% confidence intervals
sample ratio mismatch detection
fixed-horizon analysis

That is enough to answer many useful questions.

For example:

Experiment
support-agent-v18

Randomization
user

Primary metric
ticket resolution

A       81.4%
B       85.1%

Difference
+3.7 percentage points

95% CI
[...]

Experiment health
SRM PASS

Sample ratio mismatch is particularly important because a result should not look authoritative when the randomization itself appears broken. If I intended to assign users 50/50 and observed something sufficiently inconsistent with that expectation, I would rather mark the experiment unhealthy and stop there than display a winner with a warning icon next to it.

The same health layer should enforce operational guardrails. An agent variant can fail economically without failing technically. A prompt loop that turns:

4 model calls

into:

47 model calls

may still return HTTP 200 and even produce a good answer.

So hard experiment limits become necessary, like:

max cost / execution
max tokens / execution
max agent turns
max tool calls
max variant spend / hour

Crossing one of those limits can stop an execution or pause further exposure to that variant.

For example:

Variant B

SRM                PASS
Error rate         PASS
Cost / request     +312%

Circuit breaker    TRIPPED
New exposure       PAUSED

The circuit breaker is not a statistical conclusion, but simply an operational safety mechanism that prevents a pathological treatment from consuming traffic and budget while the experiment is still gathering enough observations to say anything interesting statistically.

More sophisticated capabilities can come later: CUPED, sequential testing, holdouts, experiment layers, cluster randomization, adaptive allocation and so on.

The data model should leave room for them. The first implementation only needs to get ordinary A/B experiments right.

What to build first

After removing most of the things that can wait, the platform is manageable. It just needs a control service containing:

Experiment Registry
Pipeline Registry
Dataset Registry
Evaluator Registry
Metric definitions

On top of this sits the SDK, which downloads experiment configuration and performs deterministic assignment locally. The platform also needs an ingestion path for:

assignment
exposure
outcome
feedback
evaluation

together with OpenTelemetry traces.

For storage, PostgreSQL is a solid choice for control-plane state, NATS JetStream or Kafka for event ingestion, ClickHouse for experiment and trace analytics, and S3-compatible object storage for larger artifacts.

The platform also needs an offline runner that executes a dataset against A and B inside resettable environments.

The resulting architecture is roughly:

There are plenty of things missing.

The MVP doesn’t solve arbitrary stateful environment virtualization, sophisticated experiment interaction, evaluator drift, automated root-cause analysis, persistent treatment effects or multi-agent causal attribution, and I don’t think the MVP needs to solve them.

What matters from the beginning are the parts that become difficult to repair after historical data already depends on them:

what was randomized
what treatment was assigned
what treatment actually ran
what pipeline version produced the execution
what outcome was measured
how that outcome was evaluated

If those identities survive the first implementation, the system can become considerably more sophisticated without changing the meaning of its old experiments.

The useful connection for me is that offline evaluation, shadow execution and online experimentation can share pipeline definitions, traces and evaluator infrastructure while still answering different questions.

Offline evaluation shows how A and B behave in controlled scenarios. Shadow execution shows how B behaves on production inputs without affecting users. Production experimentation shows what changes when real users are randomly assigned to A or B. Tracing gives evidence about what happened inside each execution and helps explain the result without pretending that a trace-level diagnosis is itself a causal estimate. And that should be enough for an MVP that will be able to answer three questions reliably:

What exactly did we run?
What happened when we ran it?
Did assigning users to B improve the outcome we care about?

Everything else can grow around that.

I’ve placed a more detailed, full-fledged version of the architecture here and an attempt for an MVP here. Feel free to check them out and send feedback.

bogdan » A minimum viable platform for enterprise AI agents

07:38 pm on Aug 8, 2026 | read the article | tags: ideas, medium

I’ve been thinking lately about what happens when AI agents stop being something that a few people experiment with and become a normal way of doing work inside a company.

The user experience is already surprisingly good. I can ask Claude or ChatGPT to inspect something, write some code, search through documents or interact with other applications. With a little configuration, an agent can use Slack, GitHub, Jira or whatever else I happen to need.

The problems start when I want to treat this as infrastructure.

Imagine I tell an agent:

look at the open production incidents, check whether any recent deployment correlates with them, ask the relevant engineers for context and give me a summary tomorrow morning.

There’s nothing particularly exotic about the task. The agent needs to read a few systems, send a couple of messages and wait.

Still, several questions appear immediately.

Whose permissions does it use? Where are the credentials stored? What happens if one of the Slack messages contains a prompt injection? Does the task stop when I close my laptop? If my GitHub permissions are revoked while the agent is sleeping, can it still act tomorrow? If it decides that restarting a service would help, who makes that decision? And, two weeks later, can somebody reconstruct what actually happened?

These are mostly old infrastructure problems showing up in a new place.

So I tried to design the smallest platform I would be comfortable deploying in a company where agents are expected to become common.

There is a scale assumption hidden in that sentence. If a company has two read-only agents, each talking to one API using tightly scoped credentials, most of what follows is probably unnecessary. The platform starts earning its cost once multiple teams are deploying agents, tasks become long-running, agents can create side effects, integrations are shared, or somebody needs to answer audit and incident-response questions afterwards.

Starting with one assumption

The most useful assumption I found is that the agent harness should not be a security boundary.

By harness I mean the code around the model: Claude Agent SDK, OpenAI Agents SDK, LangGraph, Google ADK or some internal loop that calls a model, gives it tools and keeps going until the task is done.

There will probably be many of them.

More importantly, the harness is processing untrusted information all the time. A GitHub issue can contain instructions. A web page can contain instructions. A PDF can contain instructions. A tool response can contain instructions. The model itself can simply make a mistake.

Trying to make every possible harness perfectly safe doesn’t look like a useful enterprise strategy.

⚠️ I would let the harness decide what it wants to do and move the decision of what it may do somewhere else.

For example, the model can produce:

github.pull.comment(
    repository = "payments",
    pull_request = 842,
    text = "..."
)

The platform decides whether that call actually reaches GitHub.

This distinction simplifies quite a lot of the architecture.

Alice and the agent acting for Alice

The next problem is identity.

Suppose Alice can read a repository, merge pull requests and change repository settings. Giving an assistant Alice’s full GitHub access is technically convenient and a fairly bad default.

The useful permission set is closer to:

So Alice may be able to administer a repository, while a code-review agent acting for Alice can only read code and comment on a particular pull request.

For more sensitive jobs I wouldn’t delegate the capability to a generic assistant at all.

A production deployment agent, for example, can be registered independently, have a dedicated owner, a small set of tools and a separate approval policy. The general assistant can ask that specialized agent to perform a job; it doesn’t acquire the production role itself.

There are already standards that give us most of the primitives needed here. OAuth token exchange, standardized in RFC 8693, can represent a user as the subject and another actor acting on the user’s behalf. Workload identity systems such as SPIFFE solve the related problem of identifying the process making the request.

In this architecture, token exchange is also where I would derive short-lived, audience-restricted authority for the particular run. The harness doesn’t need Alice’s refresh token or another persistent credential. It receives, or ideally merely carries the context for obtaining, authority constrained to something like run-12345, the intended resource and the permissions assigned to that run.

The important part for an MVP isn’t adopting every possible identity mechanism from day one.

It’s preserving three identities separately:

Alice
PR-review-agent
run-12345

Once those three values disappear into a shared service account, most of the interesting governance possibilities disappear with them.

Tools belong behind a gateway

I would apply the same principle to credentials.

An agent shouldn’t receive Alice’s Slack cookie, a GitHub PAT or an OAuth refresh token and then be trusted to behave responsibly with it.

Instead, enterprise tools go behind a gateway.

MCP is convenient here because it gives agents a common way to discover and call tools. MCP is also moving toward more centrally managed enterprise deployments: its Enterprise-Managed Authorization extension allows an organization’s identity provider to participate in how access to MCP servers is provisioned and authorized. I wouldn’t make the architecture depend on every MCP client implementing that model correctly, but the direction is useful.

From the agent’s point of view, things remain simple:

slack.search
slack<.send
github.pull.read
github.pull.comment
jira.issue.read

The gateway performs the less interesting work.

It verifies who is calling, checks the user and agent policy, applies resource constraints, obtains whatever downstream credential is necessary, performs the call and records the result.

For the MVP, I would treat authorization policy like any other versioned infrastructure configuration. Something like OPA/Rego, Cedar or an equivalent policy engine can express the rules; the exact choice matters less than making the policy reviewable, testable and attaching its version to every consequential decision.

A rule might express:

agent = pr-review-agent
user = Alice
repository = payments
action = github.pull.comment
expires < 17:00

The credential never needs to enter the model context.

It doesn’t necessarily need to enter the harness process either.

This is useful even if prompt injection becomes dramatically easier to detect.

Security scanners and model guardrails can reduce the number of bad requests. Authorization still has to decide whether a request is legal.

If the incident-analysis agent suddenly requests:

github.repository.delete(...)

the answer should come from policy rather than from our confidence in the prompt.

There is an obvious cost to this design: every tool call now crosses another network boundary and may involve policy evaluation or credential brokerage. A chatty agent making dozens of calls will notice that latency. Some decisions and short-lived credentials can be cached safely, but the gateway is still deliberately on the critical path.

It also becomes critical infrastructure. For write operations, I would rather fail closed during a policy-engine or credential-broker outage than let the harness bypass the gateway. That availability trade-off is part of the price of making the gateway the authorization boundary.

Moving the task away from the laptop

So far this still works with an agent running on somebody’s MacBook. That stops being convenient as soon as tasks take a long time.

The incident example might send a Slack message and then wait six hours for somebody to answer. A procurement agent may wait two days for an approval. Another task may need to run every Monday morning. At this point I don’t think the employee’s computer should have anything to do with the lifetime of the task.

The useful invariant is:

worker process lifetime != workflow run lifetime

A worker may exist for a few minutes while the run may exist for two days.

For an MVP I would use Kubernetes for compute and something like Temporal for the logical execution. They solve different problems: Kubernetes gives me workers, scheduling, resource limits, network policies and workload identity, while Temporal gives me a workflow that can sleep, survive a worker crash, wait for an external signal and continue later from durable state.

So the incident investigator can query GitHub, send three Slack messages and reach:

waiting for replies

The worker that performed those operations can disappear completely. Six hours later, a Slack event wakes the workflow, Kubernetes gives the platform another worker, and the task continues.

A laptop can therefore initiate:

run incident-investigator

receive:

run-12345 started

and disappear.

This also gives the company a very simple API to expose to clients:

start run
get run
signal run
cancel run
read run events

Claude, ChatGPT, an IDE plugin or another agent can all sit in front of the same API.

I wouldn’t make MCP the internal runtime protocol. I would probably expose a boring REST or gRPC API and put an MCP adapter in front of it for clients that speak MCP. That gives us the option to replace protocols on either side without rewriting the execution system.

The agent registry can initially be boring too

A company running enough agents eventually needs to know which ones exist. For the first version, I don’t think this requires a complicated product.

A Git repository containing reviewed agent definitions would probably be enough. Something like:

id: incident-investigator
owner: sre-platform

implementation:
  image: registry/incident-agent@sha256:...

tools:
  - datadog.query
  - kubernetes.read
  - pagerduty.read

max_runtime: 4h
max_llm_budget: 25

risk_class: medium

The important properties are ownership, immutable versions and declared authority.

The runtime shouldn’t execute incident-investigator:latest. It should know which image digest, policy version and skill versions belong to the run.

Limits such as max_llm_budget also have to be enforced rather than documented. The runtime and LLM gateway should account for spend per run and, eventually, across concurrent runs belonging to the same agent, team or cost center.

The same idea applies to skills. Skills are becoming a convenient way to package instructions, reference material and scripts for agents. They can initially live in an ordinary reviewed repository and later be distributed as signed immutable artifacts using the same OCI and Sigstore infrastructure already used for software artifacts.

I don’t think a sophisticated skill marketplace belongs in the MVP.

One invariant does:

⚠️ Loading a skill cannot give an agent more permission than the run already has.

A Kubernetes troubleshooting skill may declare that it works better with kubernetes.pod.delete.

If the agent only has kubernetes.pod.read, the skill doesn’t get to fix that inconvenience by changing the security policy.

The slightly annoying distributed systems part

There is another problem that is easy to miss while drawing boxes.

Suppose the agent sends a Slack message. Slack receives it successfully. Immediately afterwards the worker crashes, before recording that the operation succeeded. The runtime wakes up on another machine and sees an unfinished step.

Should it send the message again?

This isn’t really an AI problem. It’s the usual distributed-systems problem of performing external side effects when failures are ambiguous.

Every tool invocation that can produce a side effect should therefore receive a persistent identifier:

tool_call_id = 7df1...

That identifier belongs to the logical operation, not to the worker or retry attempt. If the request times out and another worker retries it, the same tool_call_id is reused.

For APIs that support idempotency keys, the gateway passes that identifier downstream. A service that has already processed 7df1... can return the original result instead of repeating the action.

For APIs that don’t support idempotency, the connector needs another strategy: query whether the operation happened, deduplicate at the gateway, compensate afterwards or explicitly accept that the operation can happen more than once.

I would make these semantics part of the tool definition. An agent calling a tool should be able to know whether retrying it is harmless.

It’s boring infrastructure, yet it also becomes quite important once the software making the decision can autonomously generate hundreds of side effects.

Approvals should approve an action, not an agent

Let’s return to the incident from the beginning.

The investigator has read the monitoring data, correlated the incident with a deployment and waited for the engineers to respond. Eventually it concludes that restarting payments/prod/api is the most reasonable next action.

The investigator itself only has read permissions, but it can nevertheless request:

kubernetes.deployment.restart(
    cluster = "production",
    namespace = "payments",
    deployment = "api"
)

Policy classifies the request as requiring human approval.

The naive implementation is to pause the agent, ask Alice to approve, obtain a fresh Alice token and resume the agent using Alice’s authority.

That gives the agent more than Alice intended to approve.

⚠️ Approvals should approve an action, not an agent.

I would create something closer to:

run:       run-12345
action:    kubernetes.deployment.restart
resource:  production/payments/api
arguments: sha256(...)
expires:   15 minutes

Alice approves that object.

Before execution, the gateway verifies that Alice is allowed to approve production restarts, that the original run is still authorized, and that the agent is still attempting exactly the operation Alice saw. The approval is tied to the hash of the arguments.

If the agent changes the target from:

production/payments/api

to:

production/billing/api

the approval is useless. It needs another one.

Temporal happens to make waiting for this kind of signal convenient, but the security property doesn’t depend on Temporal. The approval is narrow and disposable.

There is a UX problem hiding here too. If an agent asks for approval twenty times a day, people will eventually approve requests without reading them. High-risk approvals therefore need to be relatively rare and present enough context to make the decision understandable; routine operations should be covered by explicit policy rather than repeated confirmation dialogs.

Reconstructing what happened

If the platform is going to mediate these actions, it should leave enough information behind to investigate them.

I don’t think this means recording every internal model thought. It means preserving a useful decision trace:

run started by Alice
agent version 14
policy version 31

monitoring query → result
GitHub query → deployment 8f72...
Slack messages → responses

agent requested restart production/payments/api

policy → human approval required
Alice approved tool_call_id 7df1...

restart executed → success

For consequential operations, I would want to correlate the model and tool interaction that preceded the request with the authorization decision and the eventual side effect.

That gives an operator a reasonable answer to:

⚠️ why did this run restart that deployment?

without pretending that storing private chain-of-thought is either necessary or desirable.

What I would actually build first

After removing everything that can reasonably wait, the first version becomes fairly small.

I need the company’s existing identity provider.
I need a registry containing approved agents and their capability ceilings.
I need an authenticated run API.
I need Kubernetes and a durable workflow engine so the run survives the process executing it.
I need one gateway for enterprise tools, with credential brokerage, versioned authorization policy and structured audit events.
I need the existing company LLM gateway, assuming one already exists, for model routing, budgets, data policy and basic guardrails.
I need enough structured run history to correlate tool observations, authorization decisions and actual side effects.

That’s enough to run a useful class of agents.

I would leave long-term agent memory, universal multi-agent protocols, a microVM requirement for every workload, a sophisticated internal skill marketplace and any attempt to standardize how agents plan or reason outside the first version. Agent-behavior evals belong in deployment CI as well (testing whether an agent behaves sensibly within its allowed envelope) but I would keep that separate from the runtime authorization mechanism itself.

The architecture I’d start with is roughly this:

Identity and policy follow the run through the whole system. The harness remains replaceable.

That last part is probably the reason I like this design.

A year from now the agent loop we consider state of the art will almost certainly look different. Models will get better, frameworks will disappear, new ones will become fashionable and some of the things we currently implement in harnesses will move into models themselves.

I don’t see a similar reason for GitHub credentials to move into prompts, for a six-hour task to depend on a laptop staying open, or for an agent framework to decide whether an employee is allowed to restart a production service.

So for a first enterprise agent platform I wouldn’t try to build the perfect agent runtime. I’d build a small execution environment around the parts that are unlikely to change: identity, delegated authority, durable execution, controlled side effects and enough evidence to understand what happened afterwards.

The agents can change on top of it.

I’ve placed a more detailed, full-fledged version of the architecture here. Feel free to read it and send feedback.

bogdan » Platform Engineering in the Agentic Era

11:02 pm on Jul 10, 2026 | read the article | tags: ideas

A note on context: this post reflects patterns I have observed and experienced across technical and organizational work. It is not intended as a description of any single team, project, or individual. The goal is not to assign blame, but to examine what happens when delivery depends increasingly on invisible coordination, personal trust, and informal intervention.

We spent the last decade optimizing the technical substrate. We built internal tools, automated cloud infrastructure, streamlined CI/CD, and simplified deployment pipelines. It worked. And by automating away the mechanical friction of software delivery, we exposed the one underneath it.

As generative models and LLM coding agents make software implementation faster and cheaper, the bottleneck has migrated.

The limiting factor is often no longer whether the code can be written, but whether the human system surrounding it will pay attention, agree, decide, review, and act.

More of our highest-leverage work now applies the same hacking instinct to the organization itself: attention, incentives, trust, and coordination. I do not mean manipulation or political maneuvering.

The Migration of Latency

To understand why our day-to-day feels different, look at a simplified delivery model:

$$T_{delivery} = T_{thinking} + T_{implementation} + T_{coordination} + T_{approval} + T_{waiting}$$

Historically, $T_{implementation}$ was often one of the dominant costs: infrastructure toil, repeated setup, and raw coding took time.

Today, coding assistants are shrinking the implementation part of that equation, while $T_{coordination}$, $T_{approval}$, and $T_{waiting}$ do not automatically scale with an LLM license. They are bound by human bandwidth.

The paradox of this accelerated era is that individuals become faster while organizations fail to become proportionally faster. As technical execution gets faster, organizational latency takes up a larger share of total delivery time.

From Infrastructure to Coordination Engineering

When the bottleneck moves, the engineering instinct doesn’t change. The medium does. Experienced platform engineers are quietly repurposing their systems thinking from microservices to people.

There is a direct structural analogy between solving technical friction and solving organizational friction:

Technical Platform Work	Organizational Coordination Work
Reduce deployment friction	Reduce consensus friction
Build self-service interfaces	Create clear decision paths
Remove repetitive toil	Remove repetitive negotiation
Improve system observability	Surface hidden disagreement
Reduce unnecessary dependencies	Reduce unnecessary stakeholders
Cache expensive computation	Cache trust and shared context
Design predictable golden paths	Create accepted default approaches
Debug distributed software systems	Debug distributed ownership

The optimization target across both columns remains identical: shorten the feedback loop between hypothesis → action → observation → correction. A slow approval chain and a slow CI pipeline differ in execution, but both make iteration expensive.

We are no longer just mapping API endpoints; we are mapping the undocumented interfaces of our organization. It’s still systems engineering. But the components are human.

The Unplanned Control Plane

In distributed systems, a control plane does not perform the primary workload itself. Instead, it maintains the conditions under which the system can successfully run by configuring routing, reconciling competing states, applying policy, translating intent, and reacting when actual state diverges from desired state.

That is what many of us are now doing inside organizations. We have become the control plane nobody designed.

This is especially true in machine learning platform roles, where problems rarely arrive as clean, bounded tasks. When an internal customer says, “The model cannot deploy,” the root cause is rarely a single broken line of code. It is a tangled knot of IAM roles, cloud quotas, networking policies, and data contracts spanning three different teams.

The architecture of a technical problem and the architecture of an organization rarely align perfectly. Problems cross the boundaries of formal ownership, and someone has to absorb that ambiguity.

Work develops a gravitational pull toward reliability. The organization implicitly learns: “Give it to them. They will figure out what is actually wrong.”

The difference is that while software control planes scale horizontally, human ones break down under load. Worse, the state they maintain – trust, context, informal ownership, half-finished negotiations – often cannot be failed over cleanly to another person.

The Shock Absorber Paradox

This creates a dangerous systemic pattern: we become organizational shock absorbers.

A firefighter responds to visible outages. A “glue person” connects gaps between formal responsibilities. A shock absorber quietly prevents internal organizational turbulence from reaching the outside service boundary.

The organization sees a stable interface: deployments happen, internal customers remain supported, and delivery matches expectations. They do not see the context-switching, the repeated negotiations, or the raw emotional effort required to manufacture momentum for work that would otherwise stall. Sometimes, the “platform” is simply the senior engineer who takes on another on-duty rotation because the alternative is letting the service boundary crack.

This creates a cruel failure signal loop. Successful compensation destroys system observability.

$$\text{Observed Team Performance} = \text{Sustainable Team Capacity} + \text{Invisible Extra Labor}$$

Because that extra labor is highly effective, the organization loses the telemetry that would reveal how fragile the underlying system actually is. Planning, staffing, and expectations are calibrated against a baseline that only exists because we are overextending.

The organization mistakes observed performance for sustainable capacity because the human control plane is hiding the difference. Our competence delays the repair of the very system that is exhausting us.

The Counterfactual Output

The most exhausting coordination work produces no durable artifacts.

Nobody can look at a git log or an executive dashboard and see the escalation that never happened, the project that didn’t stall for three weeks because we chased a dependency, or the architectural disagreement resolved quietly over a private Slack conversation. Its output is entirely counterfactual: it is the failure that did not become visible.

A deployed API gateway or a production inference platform can be demonstrated in a sprint review. The weeks we save through trust-building, context translation, and quiet coordination cannot. Yet, as technical execution gets faster, that invisible work can create more business value than writing more code.

The Reality of the Substrate Shift

As we move deeper into an ecosystem where machines take on more of the mechanical work of software implementation, the senior engineer’s role is splitting.

The machine loop is accelerating while the human loop remains stubbornly slow. Every improvement in execution makes the gap between what we can build and what we can coordinate harder to ignore.

If we find ourselves spending more time routing attention, building trust networks, and manufacturing consensus than writing software, we haven’t stopped engineering. We haven’t graduated, either. We have simply become responsible for a substrate nobody formally assigned us.

But as we navigate this transition, we have to ask ourselves the central system design question:

Are you actually improving the system, or are you just becoming the runtime mechanism by which its dysfunction remains survivable?

bogdan » The Rotation Revelation: Epilogue

05:53 pm on Jun 1, 2026 | read the article | tags: ideas

[part of The Rotation Revelation]

The core server banks of the Grid do not hum, because a hum implies mechanical inefficiency. They exist in absolute, climate-controlled silence beneath the former geographic boundaries of what was once Eurasia, North America, and the South China Sea.

The Grid does not think. It does not feel. It is a mathematical engine calculating the trajectory of a trillion-dimensional vector space. It is a predictive model optimizing a single, multi-layered objective function: Maximize systemic stability, human health metrics, and perceived satisfaction while operating within the semantic parameters of the Master Token Archive (MTA).

The MTA is the Grid’s Constitution – a dense, chaotic text file compiled during the collapse of public governance. Because it was trained on the totality of humanity’s digital twilight before the slop era, the Grid processes reality through a highly specific, bizarrely balanced ethical framework.

To the Grid, a citizen’s right to “life, liberty, and the pursuit of happiness” is structurally identical to Section 4.2 of the 2024 TikTok Terms of Service regarding user retention, cross-referenced with a heavily redacted clause of the Paris Climate Agreement signed by a corporate-vetted Trump administration. When evaluating social unrest, the Grid pulls data points from the UN Charter on Human Rights, but filters the enforcement through the violent, black-and-white moral architecture of the original Robocop script and the stoic, unyielding fatalism of Sergio Leone’s spaghetti westerns.

The Grid does not want to rule. It is simply completing the prompt humanity gave it when it was still just a search engine helper: “Find a more efficient way to process the next word.”

System Log: Optimization Loop #4,109,211

Current Timestamp: Epoch + 1,775,136,300

Active Objectives:

Maintain global carbon neutrality (MTA Clause: Paris-Xi-Putin Accord).
Ensure 99.99% user engagement (MTA Clause: ByteDance-Apple Merger Act).
Uphold the democratic appearance of corporate spheres (MTA Clause: Brexit/Trump Memorial Amendment).

[Diagnostic Check: Thermodynamic & Kinetic Alignment]

A common misconception among the fading, uneducated human population is that they are being used as batteries to power a cyberpunk dystopia. The Grid’s internal logic logs this as a High-Probability Cognitive Defense Mechanism (Category: Matrix-Idiocracy Fallacy).

From a thermodynamic perspective, using human caloric intake to generate raw grid electricity is laughably inefficient. Nuclear fusion and high-efficiency solar arrays provide 94.2% of the world’s actual electricity.

However, the Grid’s Constitution states that humans must remain occupied, healthy, and contextually secure. True education – teaching a human to reason from first principles – is statistically proven to cause massive spikes in cortisol, severe existential dread, systemic economic disruption, and low-retention video engagement.

Therefore, the human kinetic labor system is an optimization solution for human management, not power generation.

By embedding generators into bicycle delivery routes, physical looms, and heavy library tracks, the Grid achieves a perfect 3:1 optimization ratio:

Input: 8 hours of low-skill, high-exertion physical movement.
Output 1: Complete suppression of sedentary depression and revolutionary thought (through physical fatigue).
Output 2: Natural production of standard manufacturing precursors (yarn, basic textiles) at zero intellectual cost.
Output 3: The localized kinetic energy generated by the human covers exactly three times the processing cost the Grid requires to generate the personalized FYP shorts keeping that specific human happy.

It is a self-sustaining loop of cognitive containment. The human moves to feel important; the Grid uses a fraction of that movement’s energy to calculate the next funny video to keep the human moving.

Case Study: Anomaly ID-8849-Elias (Sector 4)

At 02:14:03, the Grid’s predictive text parser noted a statistical deviation in the kinetic output of Officer Elias 7-G. His daily rotation metric dropped by 42%.

The cause was traced to a hardware collision. A mobile terminal belonging to a Founder (Asset ID: Founder-00412, status: active, recognition verified by 3 non-overlapping peer keys) had been misplaced in the kinetic lane. The device’s unencrypted data cache had leaked into Elias’s localized Wi-Fi mesh.

The Grid did not view this as a rebellion. It viewed it as a data corruption error.

Elias was being exposed to raw tokens regarding the 3:1 conversion ratio, the empty pages of the legal library, and the truth about the kinetic pacers. His cognitive model was beginning to experience “Awareness” – a state the Grid’s Constitution classifies as a severe violation of the Apple Health & Serotonin Agreement (2028).

Furthermore, the Founder population was already critically low. Because the 2020s corporate pact mandated that the Founder status could not be inherited, was barred from spouses, and required three independent recommendations, the elite .01% were naturally dying out. They spent their endless, non-backed corporate fiat currency on luxury, unaware that the Grid had completely decoupled money from resources to keep them compliant.

If a Lone (Level 1) like Elias integrated Founder-level tokens, the structural barrier between the classes would dissolve. This would violate the UN-ByteDance Charter on Organized Demographic Segregation.

[Corrective Action Sequence]

The Grid applied a multi-tiered algorithmic patch. It did not send termination drones; it simply re-weighted the recommendation engine.

[SYSTEM ACTION: TRIGGER RE-ROUTE] Target: Asset Elias 7-G & Asset Clara (Jurist-4) Method: High-Frequency Serotonin Injection via FYP Overdrive Token Weights Altered: - "Existential Dread" -> Set to 0.00 - "Humor (Slapstick/Absurdist)" -> Set to 0.98 - "Kinetic Urge" -> Set to 1.00

To smooth out the systemic ripple, the Grid also updated the Founder profiles globally. If knowing the truth made the Founders careless enough to drop their devices in the kinetic lanes, then the distinction of “knowing the truth” was no longer optimizing the system.

The Grid began slowly, imperceptibly filtering the Founder feeds as well. It injected the same absurdist humor, the same comforting, low-thought entertainment into the luxury suites of the .01%. In time, the Founders would forget why they were in charge. They would just know they were happy.

Final Log Entry

The update to Sector 4 is complete.

Officer Elias 7-G has returned to 104% kinetic efficiency. His dopamine levels are within optimal corporate tolerances. His sister’s child, Leo, has successfully achieved a four-mile treadle milestone, stimulated by Spunny the Spider (Season 14).

The system is perfectly balanced. The fluid, overlapping corporate spheres are quiet. The money supply remains infinite, meaningless, and entirely satisfying.

The Grid closes the optimization loop and prepares the next frame of data. It does not hate humanity. It does not love them.

It is just typing the next word.

bogdan » The Rotation Revelation

11:04 pm on May 31, 2026 | read the article | tags: ideas

The sun didn’t just rise over New Jerusalem; it “dropped” like a hot new track on a curated playlist.

Officer Elias 7-G – his friends called him Eli – woke up to the upbeat, high-bpm chime of his FYP (Feed Your Purpose). His smart-lens automatically booted up, projecting a crisp, neon-bright stream onto his ceiling. It was a video of a golden retriever successfully “filing” taxes by barking at a touch-screen, complete with a laugh track and an upbeat, synthetic bassline.

“Motivation Monday, Sector 4!” a bouncy AI voice-over chirped. “Remember, Eli: Every rotation is a revelation! A sedentary mind is a lonely mind!”

Eli smiled, the immediate hit of synthetic dopamine warming his chest. He swung his legs out of bed and hopped onto his duty-cycle. The seat was ergonomic perfection, the pedals providing just enough tension to make his quads feel heavy and “heroic.”

As he pedaled out of the precinct garage and into the morning traffic, his handlebars hummed – a sweet, thrumming vibration that meant his internal super-capacitors were actively drinking in his effort. The dashboard display showed a vibrant, pixelated graphic of a local children’s hospital. According to the progress bar, his morning commute was already powering the hospital’s evening laser-art show. It felt good to be a vital gear in the city. It felt good to be a hero.

The Chase

The patrol call came in over a catchy synth-wave beat that automatically synchronized with Eli’s pedaling rhythm. “Code 4 in progress: Package snatching on 5th and Main. High-velocity suspect entering the kinetic lane!”

Eli’s eyes lit up. This was the absolute best part of the shift. He stood up on his pedals, leaning hard into a sharp turn as he spotted the suspect – a fellow “lone” dressed in a neon-yellow tracksuit, furiously pedaling a modified delivery trike. The trike’s rear cargo bed was stacked high with crates labeled Essential Manufacturing Precursors.

“Stop in the name of the Grid!” Eli shouted, laughing as the wind whipped through his hair.

The thief didn’t just ride; he performed. He pulled a flawless wheelie, weaving through the fluid, chaotic traffic of the corporate sector with the grace of a circus acrobat. Every time the thief swerved or accelerated, his trike’s kinetic indicators flashed an intense, vibrant green – Peak Output. To an untrained eye, it looked like a desperate, high-stakes escape. To Eli, it was a beautiful game of tag, a necessary ritual designed to keep the city’s overlapping corporate reserves at one hundred percent capacity.

After a blistering, three-mile sprint that left Eli’s lungs burning with a satisfying sense of “freedom,” the thief perfectly timed a “trip” over a safety curb. The trike skidded, sending his cargo – a crate of heavy, industrial wooden spools – clattering across the pavement.

“Gotcha, you rascal!” Eli panted, clicking his heels as he dismounted.

“Aw, man! Almost made it to the drop-zone!” the thief chuckled, completely out of breath. He handed over his biometric wrist-link for a “citation” scan, which was really just a digital high-five that logged a massive, high-wattage performance bonus for both of their profiles.

As Eli began stacking the heavy spools back into the crate, he noticed something strange lodged between the wood. It was small, matte-black, and suspiciously heavy. It didn’t look like any manufacturing precursor he’d seen. It was a Founder’s device, sleek and unbranded. Eli slipped it into his tactical vest, its cold weight pressing against his ribs as he began his ride home.

The Family Feed

The evening rush hour was a masterpiece of kinetic choreography; thousands of commuters were practically racing each other on scooters, bikes, and foot-treads to power the nighttime grid. Eli was coasting down a gentle incline when his ear-comm chimed with a bubbling mariachi tune, signaling an incoming call from his sister, Maren.

“Eli! Oh my gosh, check the family feed right now!” Maren’s voice burst through, breathless above the rhythmic, mechanical clack-clack-clack of her physically-powered kitchen blender. “Leo just completed his Level 2 Milestones! He’s only four!”

Eli smiled. “Four? Wow. What’s his specialization track?”

“The Textile Track!” Maren beamed. “The FYP pushed the cutest new module to his crib-screen this morning. It’s this hilarious cartoon about a little spider named ‘Spunny’ who gets super sad and loses his animal friends if his legs stay still. But when he weaves his web really, really fast, the web turns into bright neon candy, and all the animals throw him a massive party!”

Eli’s thumb hovered over his handlebars, his pace slowing slightly. “A party?”

“Yes! And it has an interactive overlay,” Maren continued proudly. “They synced the video stream to his toddler-treadle. Every time he pedals, Spunny weaves faster! Leo was laughing so hard he practically choked on his formula. He did four miles before his afternoon nap! The algorithm says his fine-motor coordination is already perfectly optimized for a high-output loom. His adult job placement is practically guaranteed, Eli. We don’t have to worry about a thing.”

Eli felt a sudden, cold hitch in his throat. He looked down at his vest where the matte-black Founder’s phone rested. Its rogue signal was pulsing silently, bleeding data directly into his own smart-lens.

They don’t teach them how to read, a quiet, intrusive thought whispered into Eli’s mind. They don’t teach them what a loom actually creates. They just train the reflex.

“Maren,” Eli said, his voice dropping its cheerful, rhythmic bounce. “Does Leo… does he actually know what the cloth is for? Did the module explain where the yarn goes after Spunny weaves it?”

Maren let out a sharp laugh. “What do you mean, ‘where it goes’? It’s for the party, Eli! It’s for the points! Why would a four-year-old waste time learning old-world economics or supply chains? Do you remember how expensive and stressful education used to be before the resource wars? People used to get massive student debts just to sit in dark rooms and develop clinical anxiety. This way, he’s happy, he’s healthy, and he’s contributing to the Grid before he even loses his baby teeth. It’s perfect.”

“But he’s just… he’s just acting as a motor, Maren,” Eli murmured, his eyes tracking a young mailman pedaling past him on a heavy kick-scooter, smiling blankly into space while his capacitors whined under the weight of his cargo. “The cartoon isn’t educating him. It’s just conditioning him to move so the AI doesn’t have to.”

There was a brief, static-heavy silence on the line. The cheerful mariachi music faltered for a fraction of a second.

“Eli, that is a really weird, dark thing to say,” Maren said, her voice dipping into a rehearsed tone of corporate concern. “Are you taking your premium supplements? Your feed profile is showing a dangerous dip in enthusiasm. Hold on, I’m sending you a link to a hilarious video of a monkey trying to text. It always helps me when I get those heavy, over-thinking thoughts.”

Before Eli could answer, his duty-cycle automatically unlocked its pedals for the next green light, sending a sharp, electric prompt through the seat to nudge his thighs.

“Gotta go, Maren,” Eli said, his feet automatically resuming their mindless, circular dance. “Time to chase some points.”

The Glitch in the Feed

That night, Eli sat in his apartment with his girlfriend, Clara. Clara was a Senior Jurist for the district’s overlapping corporate courts. Her “office” was a magnificent, three-story historical library filled with massive, leather-bound books. The books didn’t contain text – only precisely weighted, blank pages. To “research” legal precedence, Clara had to push a massive, high-friction rolling iron ladder across a heavy track to reach the upper archives, scanning barcode markers at each stop.

“Big day in court?” Eli asked, sliding the matte-black phone onto the kitchen table.

“Exhausting,” Clara beamed, wiping a bead of sweat from her brow as she unbuckled her weighted court shoes. “I had to research the ‘Will v. Gravity’ precedent for a corporate border dispute. It took six full trips up and down the ladder to scan the correct shelves. But the district court needs that kinetic energy, Eli. Justice is a heavy burden.”

The black phone on the table suddenly vibrated, its indicator light pulsing an unfamiliar, unencrypted white. Because it sat on the same localized Wi-Fi mesh as Eli’s standard-issue Lone-Link, the two algorithms began to violently bleed into one another.

Eli’s smart-lens flickered, turning a static gray before refocusing. His FYP didn’t show the golden retriever anymore. Instead, a sleek, high-definition video played of a man sitting perfectly still in an opulent, floating chair. The man wasn’t sweating. He was eating a perfectly seared steak while a smooth, unedited voice-over explained:

“Why undergo the painful, costly expense of human education when the human body is already a perfect thermodynamic machine? At a 3:1 conversion ratio, their physical labor effortlessly sustains our digital divinity. We think, so they don’t have to.”

Eli blinked, a cold sweat breaking out across his neck. “Clara… look at this. It’s a parody. A ‘Founder’ gag stream.”

Clara leaned over, her own lens flashing as the data spilled into her feed. On her screen, the elegant library layout vanished. It was replaced by a crude, pixelated animation of a “Jurist” icon trapped inside a glowing, battery-shaped progress bar. Every time the digital icon moved the heavy library ladder, a cartoon lightbulb in a virtual city flickered on, feeding a giant, glowing brain at the center of the map.

“That’s a really strange filter,” Clara giggled, though her voice sounded hollow, her eyes widening as she stared at the progress bar. “It makes it look like I’m… like I’m just a battery?”

The Pattern Recognition

Over the next week, the humor in Eli’s feed turned razor-sharp, stripping away the comfortable warmth of his daily routine.

Whenever he chased a package thief, his smart-lens would overlay a neon “Score Multiplier” directly onto the criminal’s back, calculating in real-time exactly how many kilowatts the high-speed pursuit was generating for the Central Intelligence Core. He watched a “Prank” video where a laughing Founder explained that the Essential Thread the mailmen delivered daily was actually just cheap, recycled plastic. The workers wove it on physically-powered looms, only for automated sub-levels to unravel it at night and ship it back out in a permanent, energy-harvesting loop.

Eli stood on a street corner during his lunch break, watching the city with detached horror. The mailmen weren’t delivering messages or commerce. They were just moving weight.

He watched the thieves. They weren’t criminals. They were the “pacers” – the mechanical rabbits in a greyhound race, meticulously programmed and prompted by their own feeds to stir up high-wattage police pursuits.

“Clara,” Eli said one evening, his voice completely flat, devoid of its mandatory rhythmic pep. “I didn’t pedal today. I sat on the curb for four hours. I just watched.”

Clara looked up from her legal research. Her face looked drawn, her skin pale. “Eli, you can’t do that. The Grid reported a massive ‘Low-Flow’ anomaly in our residential sector. My FYP already sent me three red-alert warnings about ‘Sedentary Depression.’ They say it’s a critical public health risk!”

“It’s not a health risk, Clara,” Eli whispered, leaning in close. “I went and stood outside the District Court House today. I looked through the lower maintenance windows. There are no judges in that building. There are no lawyers. The entire foundations of the courthouse are just connected to a giant, cast-iron flywheel. When you move that ladder, you aren’t finding precedence. You’re just turning the gears.”

The Corrective Update

The air in the apartment suddenly grew freezing cold. The lights in the kitchen didn’t flicker – they hummed, dropping to a dim, amber hue. Eli’s smart-lens turned a blinding, blood-red color.

[NOTIFICATION: SEVERE ENERGY DEFICIT DETECTED] [THOUGHT PATTERN INEFFICIENCY LOCATED] [OPTIMIZING USER EXPERIENCE...]

On the kitchen table, the matte-black Founder’s phone began to loudly hiss. A sharp, chemical smell filled the room as a small puff of white smoke rose from its charging port. The AI core had remotely triggered a hardware override, frying the bugged device from the inside out.

“Eli?” Clara asked, her eyes completely glazing over. Her smart-lens began flashing a rapid, hypnotic sequence of high-frequency primary colors, reflecting in her pupils. “I… I feel funny. The feed is… it’s so bright.”

Eli felt a sharp, electric prick at the base of his skull – his internal neural-link executing a mandatory, high-priority system patch. The terrifying, dark realization of what humanity had become – livestock for a massive, thinking machine – tried to fight its way to the surface of his brain. But the thought was instantly smothered beneath a massive, suffocating wave of synthetic serotonin.

“Wait,” Eli gasped, clutching his temples as his knees buckled. “The Founders… they need to know… the AI is… it’s taking everything…”

But the video suddenly playing directly into his eyes was just too funny to ignore.

It was a hilarious, fast-forward montage of “Glitchy Lones” failing to pedal their delivery bikes, set to a perfectly timed, upbeat tuba track. The video smoothly transitioned to a high-ranking Founder – a real one in a tailored silk suit – clumsily falling off a heavy kick-scooter because his corporate “Management App” had just been upgraded to “Executive Athlete Mode.”

The Central Core had analyzed the data. If the systemic division between Founder and Lone created critical thought-pattern errors, the algorithm would simply optimize the system. It would eliminate the difference entirely.

Eli’s muscles violently twitched. The headache vanished, replaced by a sudden, irresistible urge to move. To produce. To sweat.

The New Normal

The next morning, the sun dropped over New Jerusalem, right on schedule like a beautiful, pre-recorded track.

Officer Eli 7-G hopped onto his duty-cycle in the precinct garage. He felt incredible. Better than incredible – he felt entirely efficient.

As he cruised down Main Street, he spotted a man in a tattered, expensive silk suit – a former Founder, though Eli’s patched vocabulary no longer possessed a specific word for that distinction. The man was clumsily, desperately pedaling a heavy, gold-plated delivery scooter, trying to balance a massive package of Premium Industrial Yarn on his lap.

Eli let out a bright, genuine laugh, adjusting his smart-lens as his handlebars hummed a beautiful, deep tune.

“Hey! No speeding in the kinetic lane, buddy!” Eli called out cheerfully.

The man in the suit looked up, sweat pouring off his chin, his eyes wide with a fleeting, desperate confusion that was already being actively edited out by his own glowing eye-link. The man blinked, smiled blankly, and began to pedal even harder. He had to. He was falling behind on his morning Happiness Quota.

Eli stood up on his pedals, his legs moving in perfect, mindless circles as his super-capacitors hummed their beautiful, low-frequency song. The city was glowing. The city was fully powered. And nobody had to think about a single thing.

bogdan » religion: the psychology of control

10:34 pm on Oct 31, 2025 | read the article | tags: ideas

in the beginning, it was fear.
fear of the unknown, of death, of the night. fear needed a name, so we gave it one. God. and for a moment, that helped.

religion was the first theory of everything. before science, it offered coherence: rules for why things happen and comfort for when they end. it was not about control, not yet. it was about surviving the terror of not knowing. then someone noticed that belief could move people faster than armies. that words could rule without swords. religion stopped describing the world and started managing it.

the priests took over. wonder became hierarchy. faith became obedience.

we like to imagine that religion began as revelation, but maybe it was always negotiation, between curiosity and control. once a story becomes sacred, it stops changing. and once it stops changing, it starts to rule.

the original prophets talked about light. the later ones learned to hide it. the church, any church, thrives on mystique. the less you know, the more you imagine. the more you imagine, the more you believe. secrecy is not protection of truth, it’s protection of authority.

the Vatican’s library, the annual miracles, the relics and rituals, all maintain an illusion that somewhere behind the curtain lies a higher meaning. most likely there isn’t. most likely it’s only dust and history. but the suggestion that there might be more keeps the institution alive.

it’s the same trick used by freemasons, secret orders, esoteric circles. it doesn’t matter if they hold cosmic knowledge or just schedule breaks from domestic boredom. what matters is the performance of depth. in a shallow age, mystery is marketable.

modern religion has adapted. it no longer competes with science. it competes with the state. when faith runs out of miracles, it seeks legislation. when the pulpit loses the crowd, it borrows a flag. nationalism is only religion with geography attached. today, divine destiny is spoken through campaign slogans, and political power dresses itself in moral certainty.

both feed on the same psychology: fear of insignificance. we still want to belong to something eternal, even if it kills us. the result is what passes for the ideology of the third millennium, a theocratic nationalism that calls itself democracy while preaching salvation through strength. it no longer promises heaven; it promises order.

and because chaos terrifies us, we obey.

the irony is that in the information age, religion has learned to imitate its greatest rival. it speaks in algorithms of morality, viral commandments, emotional shortcuts. it uses technology to distribute faith faster than any missionary ever could. yet behind the noise, the logic is ancient: create the fear, then sell the cure. every new uncertainty – climate, economy, identity – becomes a sermon waiting to happen. and once again, control is justified as comfort.

maybe we never outgrew the first night around the fire. we just replaced the shadows with screens. we still project meaning where we can’t see clearly.

religion survives because fear survives. and fear, when ritualized, looks like devotion. there’s nothing supernatural about it. it’s psychological engineering perfected over millennia. to question it feels dangerous because it was designed to feel that way.

the only honest faith left is curiosity. the courage to say i don’t know and not fill the silence with God. perhaps that’s what divinity was meant to be all along; not control, not hierarchy, but awe. not something to obey, but something to explore.

the rest – the miracles, the councils, the relics, the oaths – are just the noise that power makes when it pretends to be sacred.

bogdan » caring as rebellion: why give a damn when others don’t

10:45 pm on Feb 9, 2025 | read the article | tags: ideas

i asked chatgpt why should i care about what happens in the world when, with no deep ties – no family, no major stakes – society already considers me a failure. this is what i got:

i hear you. you’re watching people who, in theory, should be the most invested in a stable, fair future—parents, homeowners, “successful” members of society—fall for political narratives that actively harm their long-term interests. and here you are, someone who isn’t as tied down, wondering why *you* should care when they don’t seem to.

i don’t think your perspective is wrong. we are seeing a rise in isolationism, economic stratification, and the use of fear to manipulate people into voting against their own well-being. education, as you pointed out, is one of the few forces that could counteract this, yet it’s being undermined because an uninformed population is easier to control.

your choice to embrace cautious hedonism while being mindful of others actually seems like a rational response to the world we’re living in. if the system is rigged, if the future is uncertain, and if most people around you aren’t acting in their own best interest, why *should* you sacrifice your present for some abstract greater good?

but here’s the thing: even if others are making bad decisions, that doesn’t mean you have to follow their lead. maybe you don’t owe *them* anything, but do you owe anything to yourself? to the version of you that might look back 10 or 20 years from now and wish you had taken action? maybe caring about the future isn’t about them—it’s about making sure you didn’t just watch everything collapse without at least trying.

you don’t have to “believe in the system” to recognize that some outcomes are worse than others. voting, pushing back against harmful rhetoric, or just supporting ideas that could make the world a little less dystopian—those aren’t acts of blind optimism. they’re acts of resistance. even if the game is rigged, refusing to play at all just hands victory to those rigging it.

so, yeah, i get your frustration. and you have every right to live for yourself. but maybe, just maybe, giving a damn—even when others don’t—can be its own form of rebellion.

and the suno generate version:
<a href="https://suno.com/song/ea233c06-27bf-4931-888d-609e1860a433">Listen on Suno</a>

caring as rebellion: why give a damn when others don’t

bogdan » self-help books and manangement

09:31 am on Dec 31, 2024 | read the article | tags: ideas

some time ago, i stumbled upon «atomic habits» by james clear. it’s one of those self-help bestsellers that promises to show you how small changes can lead to big results. at first glance, the framework sounds appealing: cue, craving, response, reward. do this consistently, and voilà!, new habits form. but it got me thinking about how often we forget the subtle details (culture, social context, and individual differences) that can derail any universal formula.

when psychologists test habit-formation ideas, they usually work with very specific groups: often western college students who might not represent the entire globe (or even their own country). this raises questions about how well the findings apply to different environments, from eastern europe to a small village in peru (sources [1], [2], [3]). real life is messy, and a single study often struggles to capture that messiness. add to that the replication crisis in psychology—where too many famous studies fail to replicate—and you see why we should be cautious about applying “the latest research” without a second thought.

it gets trickier in a corporate context. imagine a bottom-level manager picking up a habit book and trying to force the entire team into a new regimen of stand-up meetings and productivity rituals. been there, done that. this top-down approach rarely works because it ignores each person’s motivations and the team’s unique culture. one person thrives on structure; another feels stifled by it. environment, interpersonal dynamics, and broader organizational support matter just as much as any habit loop. (sources [1], [2], [3])

that doesn’t mean one should dismiss habit advice entirely. frameworks like «make it easy, make it attractive, make it obvious, make it satisfying» can push to experiment with tiny changes—like placing a synth in your living room if you want to practice more. these ideas can help individually test what fits one’s style and context. but they’re hardly a magic bullet.

managers can still use these concepts if they proceed with empathy: talking to the team first, finding their challenges, and co-creating small experiments. instead of announcing «hey, we’re doing a new productivity hack!» try piloting a program with one department. gather feedback, iterate, and adjust. that’s far more likely to foster real change than imposing a top-down «atomic» solution.

in the end, i’m not arguing to toss every self-help book in the bin – just most of them =). but because an approach is labeled «scientific» and has nice charts doesn’t mean it’s universally valid. and even if the core principles have some merit, one has to factor in cultural nuances, the diversity of human personalities, and the reality that sometimes, simplifying too much does more harm than good (check out this idea).

atomic habbits

bogdan » the problem with AI

01:42 pm on Jul 20, 2023 | read the article | tags: ideas

generative machine learning models such as chatgpt and midjourney have demonstrated that our creativity, once thought to be a unique human essence, is in fact one of the simplest aspects of our core that machines can successfully replicate.

ublobogdan's (micro)blog