Emil Tiller

My fellow Googlers recently have published a white paper on AI Agents. Many believe that AI Agent is the application layer of LLMs, and it seems like we are stepping closer to having useful and reliable AI Agents. This is a recommended must-read.

93

6 Comments

I didn’t stay and grow at Amazon for 5 years just because I could write good code. Plenty of smart engineers can do that every single day. Writing clean code was just the entry ticket. What truly set me apart was taking ownership, even when it wasn’t asked. If I was assigned a bug to fix, I could’ve stopped after the code review. But I would follow it to production, sit with support teams, talk to impacted customers, and make sure the bug was truly gone, and people felt the difference. If I was asked to build a new API, I could’ve stopped after passing the unit tests. But I’d stress-test it with real traffic, set up alerting, write docs, and hop on calls with downstream teams to make sure their integration was smooth. If I noticed on-call alerts going off every night, I could’ve shrugged and marked them as “infra issues.” But I dug into root causes, ran post-mortems, and sometimes pulled late nights re-architecting fragile parts, so the next person on call wouldn’t have to lose sleep. If I wrapped up my sprint tasks ahead of schedule, I could’ve clocked out early. But I’d sit with teammates struggling with blockers, offer code reviews, and even pick up “thankless” chores like improving internal tools or onboarding docs. Ownership isn’t about heroics or working 14-hour days. It’s about caring enough to see things through, to fix the root, not just the symptoms. To ask, “What else could go wrong?” and, “How can I make this easier for the next person?” That’s how you get noticed. That’s how you build trust. That’s how you grow. Don’t just be the engineer who writes code. Be the one who owns the outcome, end to end. That’s what really sets you apart.

297

10 Comments

This semester, I’ve been assisting the 5th-grade class at Palo Alto Unified School District (where my daughter is a student) in learning Scratch. Interestingly, several kids have expressed that Scratch doesn’t feel as “cool” as Python, which I taught them last year in 4th grade. Their main complaint? Scratch lacks actual code. While exploring alternatives, I came across an online teaching platform: Go+ Builder. It introduces a variant of the Go programming language, allowing students to drag and drop control flows into an editor window—bridging the gap between block-based and text-based coding in an intuitive way. https://lnkd.in/dBHN27YP If you’re involved in teaching programming to young learners, I’d love to hear your thoughts on similar tools! 🚀

66

3 Comments

An agent has no consistent definition. You can think of an agent as an autonomous or semi-autonomous system that can take actions on behalf of the user in a given environment, state, and make decisions or take actions that can accomplish certain tasks along a given time-frame, either by calling tools, dynamically selecting the next action to take or use a deterministic "workflow" (systems where LLMs and tools are orchestrated through predefined code paths). Using an Agent framework that gives you the ability to built systems in both, a reliable and a dynamic way can accelerate your agent development journey using agent abstractions. This means building Agentic systems that can reliably call tools, store memory (episodic/semantic/procedural), have comprehensive logging and observability, human in the loop workflows and the ability to build various multi-agent patterns flexibly based on your use case. A successful Agentic system in production is usually a combination of both, dynamic and predictable/reliable multi-agent systems. Strands Agents SDK gives you exactly these capabilities by treating each “agent” as a combination of a foundation model plus a suite of tools. You define a prompt and register your tools (decorated functions) in code, then Strands handles reasoning→planning→tool-execution cycles, local testing, and cloud deployment (ECS, Fargate, Lambda, EC2), along with support for all other agent abstractions provided above. Excited to share a hedge-fund analyst multi agent system: This uses the newest Anthropic's Claude 4 Sonnet/Opus that powers the Lead Analyst Agent, routing incoming queries to specialized sub-agents for fundamental, technical, and market analyses. Each specialist is wrapped as a callable tool (using the “agents-as-tools” multi-agent pattern), so the orchestrator never has to implement domain logic itself and can handoff the task to an agent as a tool. For sensitive operations (insider lookups), we utilize a HITL approval step that halts execution until a human grants consent. We also use meta-tooling that enables the Lead Analyst to generate, load, and invoke new custom tools at runtime—whether it’s a portfolio beta calculator or a pricer—without redeployment. Strands also embeds observability (Langfuse) and OpenTelemetry tracing so you can trace reasoning events, tool invocations, errors, and end-to-end workflows in real time. View more information on the code implementation here: https://lnkd.in/gJmwVyGi Code implementation: https://lnkd.in/gzTtJvJq Thanks to 🏄‍♂️ Cagatay Cali for being a reviewer/collaborator on this! Feel free to try it out and reach out with any questions/ideas. #aws #agenticAI #strands #agents #generativeAI

60

6 Comments

Failing the right customer-focused goal at Amazon is better than succeeding at the wrong one An engineering manager on my team once proposed an audacious goal "we will reduce server latency by 20%." We owned the navigation elements of the website shopping experience - rendered on every page so a 20% latency improvement would be huge! I was a new leader to the team and wanted to learn as much as possible, asking "How much of that 20% latency reduction will customers see?" "Customers should see about half the improvement." A 10% speed up for navigation elements for all pages at Amazon.com would be still be great! After discussion (we couldn't do more without resourcing trade-offs) I was onboard: "Great! Set the goal for a 10% customer improvement and get started!" Immediate push back. "Wait! We're only confident in the server side improvement - we might miss this goal!" They were afraid to commit even if it meant taking a server goal that might not matter to customers. This resistance meant we didn't take any latency goal and invested elsewhere. I've seen this pattern repeated since then - leaders preferring to commit to what they know they can deliver and being afraid to outline the goal impact in customer terms that would truly matter. In some cases this means the goal proposed was easily accomplished (we engineers can be a pessimistic lot). In some cases these less-inspiring goals were missed, or simply dropped. Either outcome isn't necessarily great, but missing a tightly defined goal that had unimpressive benefit reflects poorly on the judgment of a leader. Better to aim too high and miss (but get close!) than aim low and fail to impress or achieve. Within reason - teams and people will rise to higher expectations. I am guilty of over-optimism in setting goals, sometimes dramatically so. In 2021 I set a 1-year customer-obsessed goal based on "what would need to be true" hoping to inspire and exceed. We didn't make it - the goal was so audacious that I lost trust with the team "it's red from the start!" Our 2022 goal was more reasonable, but still audacious (yes - we missed that one too). We did ultimately succeed in June 2023, 18 months late -- but crucially I didn't lose the trust of my leaders along the way. We made measurable progress and I provided updates on where we were, the problems we faced, and (more importantly) how we continued to de-prioritize other goals to make the more important work happen. I learned to both educate and simplify in my updates so my leaders could understand, give helpful feedback, and support us when necessary. I helped them appreciate how hard the problems that were trying to solve were - not to excuse the misses, but to explain them. This helped me continue to have the privilege of leading my team. I was promoted in the midst of red goals - the most critical one across my org. Why? Because failing the right goal is better than succeeding on the wrong one.

138

1 Comment

My fellow principal engineer Arron Bailiss wrote an excellent blog post about the design principles of Strands Agents 🧬, what the agentic "model-driven approach" means, and guidance for how to think about multi-agent architectures. https://lnkd.in/gh5p5UXi

267

3 Comments