Strands Agent

TypeScript vs Python: Startup Perspective

Default to TypeScript for startups unless your team is Python-native:

• Most startup backends are Node/TypeScript already — one language = one deployment pipeline
• Type safety catches tool schema bugs at compile time (agent tool bugs are expensive to debug in production)
• Strands TS has first-class support and bundles Zod for tool validation

Pick Python only if: Your team is Python-first, you need Python-specific ML libraries in tools, or you need Strands Evals (Python-only).

Cost Architecture: The Tool Count Rule

Each additional tool costs you money on every single invocation because the model must reason about which tool to use. The cost isn’t just token count — it’s reasoning quality degradation.

Startup rule: If your PoC agent has > 5 tools and you have < $2K/month LLM budget, you’re over-engineering. Split into two focused agents or remove tools.

Memory: Don’t Add It Until You Need It

Memory modes ranked by startup relevance:

1. NO_MEMORY (start here): Stateless tool-calling. Cheapest. Works for 80% of startup agent use cases (internal tools, one-shot tasks, API orchestration).
2. STM_ONLY (add when): Users complain about repeating themselves within a session. Multi-turn conversations that reference earlier context.
3. STM_AND_LTM (add when): You have paying users who want personalization across sessions AND you’ve validated they actually return frequently enough for LTM to matter.

Cost of premature LTM: Memory extraction runs additional model calls per session. At 1000 sessions/day, that’s meaningful token spend for personalization most early users won’t notice.

Deployment: The Container Gotcha (TypeScript)

TypeScript agents REQUIRE containerized deployment (--deployment-type container). This means:

• ECR image build in your CI/CD pipeline
• Container image maintenance (base image updates, dependency patches)
• Slightly higher cold-start than Python agents

If you’re deploying to Lambda for cost reasons (scale-to-zero): Use Python Strands agents — they work with Lambda’s native runtime. TypeScript agents need Lambda container image support (slower cold starts, 10GB image limit).

Evaluation: Ship Evals from Day One (But Cheaply)

Counterintuitive: Most startups skip evals entirely OR over-invest in a massive eval suite. The right answer:

Minimum viable eval suite (3 evaluators, ~$5/day at 100 test cases):

1. GoalSuccessRateEvaluator — Did the agent achieve the user’s intent?
2. ToolSelectionAccuracyEvaluator — Is it using the right tools?
3. FaithfulnessEvaluator — Is it hallucinating? (Critical for customer-facing agents)

Add more evaluators only when: You have a specific quality issue you can’t diagnose with these three.

Cost trap: Evals invoke LLM-as-Judge. 9 evaluators × 500 test cases × daily = significant token spend. Start with 3 evaluators × 50 golden test cases × on-PR-only.

Gotchas That Waste Startup Time

• Default model is Claude Sonnet — expensive for iteration. Override to Nova Micro/Lite during development: saves 10-20x on development costs.
• VPC config is immutable — if you deploy with VPC settings and realize you don’t need them, you must create an entirely new agent config. Start WITHOUT VPC unless you know you need private resource access.
• agentcore destroy deletes everything — including memory resources with user data. Always --dry-run first. No undo.
• Memory provisioning takes 2-3 minutes — friction during rapid iteration. Use NO_MEMORY for development, add memory only in staging/prod configs.
• OTel is on by default in AgentCore — traces go to CloudWatch/X-Ray (which costs money). Disable with --disable-otel during early development if you’re not looking at traces yet.