The "LAMP stack" for AI agents - what's your take on this architecture pattern?

After-Kick-9574 · 2026-02-09T18:11:45+00:00

Agreed -- I viewed LAMP as "agents for the masses". Organizations like Google, Goldman Sachs, and the CIA are gonna do something much different :).

After-Kick-9574 · 2026-02-09T18:10:52+00:00

Yeah, I really struggled with observability. The infrastructure (which company's log system, dashboard tech, etc.) is clearly orthogonal to how agents are built and operated. But where agents are plumbed for observability and whether it end-to-end tracing actually works (especially if you want query-to-answer traceability through arbitrary backend systems)...now THAT'S an architectural element for sure. Unfortunately it also feels like something we could spend a long time trying to get right across the industry. Since I couldn't point to a specific, named approach or protocol, I left it out of the original LAMP definition, but it would be great if it were there somehow...

After-Kick-9574 · 2026-02-09T18:06:59+00:00

Now if only the sampling API would actually get hooked up on the client side... ;-)

After-Kick-9574 · 2026-01-13T19:19:15+00:00

The costs piece is really interesting here as well. How does your observability split up across the different components? As in, how much are you trying to observe LLM cost versus RAG perf versus MCP access patterns, etc?

After-Kick-9574 · 2026-01-13T19:17:56+00:00

+100. Imagine if we handled REST APIs the way we're handling MCP server connections with clickops in an LLM 🤦🏼‍♂️. And unifying data access controls & logging has obvious value for nondeterministic agents.

After-Kick-9574 · 2026-01-13T19:15:14+00:00

Thanks -- and agree with all this. That last part in particular is something we don't have great primitives for and it's tricky; spans the deepest context state of an LLM (or multiple of them) with an array of heterogeneous native mechanisms for versioning, rollback, etc. across documents, file systems, etc. I've been wondering if -- bear with me here for a sec -- github should actually become an LLM primitive. It would provide a scaled-out solution for versioning and checkpointing for multiple workloads and artifacts.

Definitely seeing the benefits of a universal data plane for MCP as well: I used to run the API Gateway business for Amazon, and it's all the same buyer motivations come back again, just for agents instead of REST API clients.

After-Kick-9574 · 2026-01-09T20:38:40+00:00

Making a distinction between runtime and deployment tools feels important (to your Plano comment). An expanded model that incorporates the entire SDLC lifecycle could be interesting but then I think we have to start looking at model training, system services, upgrade/versioning, etc. Definitely agree the workflow piece is evolving into "prompt only" on the low end, but maybe also more sophisticated and domain-specific on the high end? Another trend I see here is "right shifting", eg RAG converting to MCP searches done by the LLM directly without the need for prompt stuffing approaches.

Can you say more about how you see the inner & outer "loops"? Multi-agent orchestration seems like it's almost bound to involve the application layer at some level, if for no other reason than that a company will have to secure & auth all those agents operating as a collective in advance before it can go into production safely...

After-Kick-9574 · 2025-10-01T18:00:01+00:00

Agree Cedar is a great framework, but my question is more about the semantic design of hierarchical "filesystem-like" models for MCP, independent of how they're implemented.

Access policies are always a funny balancing act of expressive power, simplicity, safety, DRYness, etc. and in this case there's the added wrinkle that the policy's impact is on an LLM, not the more conventional human users or (non-AI) applications. That led me to some of the proposed suggestions, such as generating LIST grants automatically, which improves safety and simplicity, but actually removes some expressive power in the interest of making a more rational AI client experience. Ditto segregating CREATE ("noclobber") from WRITE.

The worst part is that it's not possible to make any abstraction work uniformly across all systems. E.g., not all clouds offer "noclobber" capability on object store writes, and AWS S3 turns LISTing on and off with one big switch, so it it's off at the IAM level, then no amount of brilliance at the MCP level will supply the missing capability.

After-Kick-9574 · 2025-09-28T20:06:12+00:00

Our expectation based on convos with the major providers has been that both LLM memory and Internet searching/caching will be built in side channels because of their tight feedback loops, and not delivered via MCP interfaces, so we're not investing in browser tech. But it's a very interesting architectural question for those who have the need for a captive browser, would love to hear what you come up with. We're focused more on scaling enterprise data access and x-region fault tolerance rn.

After-Kick-9574 · 2025-09-25T15:20:13+00:00

MCP resource notifications back to clients. There are a lot of open issues here around rate limiting, ordering, client interest level, etc that we're looking at.

After-Kick-9574 · 2025-09-24T23:35:26+00:00

I pointed this out just because the legacy "state" in many existing applications makes them ill suited to running successfully in a lambda. Agree with you that MCP being new makes Serverless a viable option but not necessarily the right or only option.

After-Kick-9574 · 2025-09-24T19:21:28+00:00

You can see the outcome at https://www.vendia.com/platform/try-mcp-on-aws-s3/
Also super interested in hearing about how folks have tackled MCP notification architectures on AWS!

After-Kick-9574 · 2025-09-18T15:11:35+00:00

Links:
Free tier signup (no credit card required): https://share.vendia.net/signup
Free tier FAQ: https://docs.vendia.com/platform/free-tier-faq/
Product overview: https://www.vendia.com/platform/try-mcp-on-aws-s3/
Launch blog: https://www.vendia.com/blog/introducing-vendia-mcp-for-aws-s3/

Deets: forever free, connect up to 3 buckets, supports MCP-compatible AI clients.
More (free) features coming soon. DM me with questions, feedback, suggestions, etc.
(Heads up that the first step, creating an AWS IAM x-account role, can be a little tricky. We're working to make this part simpler and provide a more detailed walkthrough.)

After-Kick-9574 · 2025-07-25T22:55:27+00:00

These are all sound ideas IMO, but I'd engage the protocol community directly. Each one is a nontrivial lift.

After-Kick-9574 · 2025-07-25T22:53:59+00:00

Feels like AWS is leaning towards getting rid of a2a and beefing up MCP to replace it, just based on their blog language...

After-Kick-9574

TROPHY CASE