Skip to content

feat: add Meeting Worthiness Judge agent sample - #12

Merged
GarrettBeatty merged 3 commits into
hackathon2026from
gcbeatty/meeting-judge-agent
May 6, 2026
Merged

feat: add Meeting Worthiness Judge agent sample#12
GarrettBeatty merged 3 commits into
hackathon2026from
gcbeatty/meeting-judge-agent

Conversation

@GarrettBeatty

Copy link
Copy Markdown
Contributor

Summary

  • Adds a new hackathon sample app: Meeting Worthiness Judge Agent — a comedic agent that evaluates whether a meeting deserves to exist
  • Uses the AgentCore source-generator pattern (attribute-based) with 5 fake tools that analyze meeting invites and deliver courtroom-style verdicts
  • Tools: CountAttendees, AnalyzeAgenda, CheckIfCouldBeAnEmail, EstimateProductivityLoss, SuggestAlternative

Test plan

  • dotnet build sampleapps/MeetingJudgeAgent/MeetingJudgeAgent.csproj compiles successfully
  • dotnet run --project sampleapps/MeetingJudgeAgent starts on port 8080
  • POST to /invocations with a meeting description returns a comedic verdict
  • GET /ping returns healthy status

🤖 Generated with Claude Code

A comedic hackathon agent that evaluates whether a meeting deserves to
exist. Uses five tools (CountAttendees, AnalyzeAgenda, CheckIfCouldBeAnEmail,
EstimateProductivityLoss, SuggestAlternative) to gather "evidence" and
delivers a formal courtroom-style verdict.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@GarrettBeatty
GarrettBeatty requested review from a team as code owners May 6, 2026 15:38
@GarrettBeatty
GarrettBeatty requested review from normj and philasmar and removed request for a team May 6, 2026 15:38
@GarrettBeatty
GarrettBeatty merged commit abc189e into hackathon2026 May 6, 2026
1 check failed
@dscpinheiro
dscpinheiro deleted the gcbeatty/meeting-judge-agent branch June 29, 2026 02:30
GarrettBeatty added a commit that referenced this pull request Aug 18, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 18, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 19, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 21, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 21, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
GarrettBeatty added a commit that referenced this pull request Aug 24, 2026
Lets the policy backend evaluate tool-call context with inline guardrail checks
(content filter, prompt attack, sensitive information) so no pre-created Bedrock
guardrail is required, streamlining onboarding (design decision #12).

- Bumps AWSSDK.BedrockRuntime to 4.0.101.1 (adds InvokeGuardrailChecks).
- GuardrailChecksOptions: categories/entities to check plus severity/confidence
  thresholds. BedrockGuardrailsPolicyOptions.InlineChecks selects the mode.
- BedrockGuardrailClient.InvokeChecksAsync builds/times the request;
  GuardrailResponseMapper.ChecksTripped maps per-check scores to a deny
  (fail-safe: a finding with no score is treated as tripped).
- The backend uses ApplyGuardrail when GuardrailId is set, else inline checks;
  ctor and setup validation accept either. Detection only (no masking), so PII
  sanitization stays on ApplyGuardrail.

Tests cover mode selection, allow/deny by threshold, and ctor validation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant